Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hi Michael,

Michael Meeks wrote (27-06-11 12:47)
On Sat, 2011-06-25 at 23:52 +0200, Cor Nouws wrote:

And indeed, I see no reason why that would be a natural thing happening.
If there is a moment that we know: QA on this build is important, do
this ... that will help focussing :-)

        So :-) now is this moment. It is important to have QA guys running the
daily builds for their day-to-day work / use-cases :-) I think this is
the basic problem, a lack of communication around what is good to be
testing, and a lack of willingness to test 'master' ( because it is too
buggy ;-) combined with a hope that master gets less buggy as/when we
release it.

How much I agree with 'important' 'good' etc. we do not have a can of QA guys that we can take from the shelves to do the work.. Many people working on QA do it besides other responsibilities, normal work, etc. Also: starting working/testing with a new version (daily build) takes time to install, set your preferences, etc etc. So that is for many people a reason not to jump on new versions every day, I guess. (Happily, I can confess that daily's / master builds are pretty OK to do your work with, so I support the ongoing effort to encourage people to pick those builds.)

        Anyhow - there are various psychological ways we can approach this, by
having a different timetable for the QA team, that has a label marked
"feature freeze" (ONO) - whatever it is that triggers you guys starting
to do the QA, at a given date, and then the coder's feature freeze a bit
later ;-) We can put the prefixes 'soft' and 'hard' on this to make it a
bit clearer even if we want.

Well, given the voluntary nature of much QA work, we have to take the tension-bow into account (no idea if that is English, but must be understandable somehow). I.e.: we cannot expect the average QA-enthusiastic to put a lot of energy in it for weeks and weeks continuously on a high level. Plus that there must be a large group, on a bit more distance, that has the attitude to start testing at the moment that the inner group is expected to be close to ready. For those reasons each special milestone is important as encouragement: ah, now I really 'must' jump in. Therefore Beta's and RC's will get much much more attention and testers. Hmm, I can hardly imagine that I write anything new here :-) Only to emphasize that it is not so wise to assume that QA activity will increase solely by us finding it important (and declaring that..)

        Anyhow - I assume you didn't submit the talk, since Drew was pointing
out the lack of papers, so I've just done that ;-)

As written: it is not at all sure that I'll be able to attend, so submitting a 'talk' that others would have to give... No I didn't.

[snip]
Title: Improving the Development / QA cycle

Short Summary:
A panel discussing how to better integrate the QA / Development cycle,
timelines, freezes and all

Abstract:
Many proposals to improve quality of the product have been made, some of
these revolve around scheduling and timing. Come hear a discussion about
our current release process, how it works what 'time based' really
means, and the impact that needs to have on our process. And hear about
what can be done to improve it from various perspectives.

I'd like to have: Cor Nouws, Rainer, Caolan, myself, Norbert, Petr
Mladek, and a few more QA'ish types of our selection :-)
[/snip]

Looks important enough. So an extra argument for me to try to be there too :-) But as explained before: deciding halfway October that time before freeze is shortened from 7 to 3 or 4 weeks, is not going to make people happy. So I insist on a sound, rational weighing of factors that influence the change that we need more time to do a sound QA in order to release a good 3.5.0. - I think we all know the importance of that.

Cheers,
--
 - Cor
 - http://nl.libreoffice.org


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.