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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
