[Libreoffice] minutes of tech steering call ...

[Cor Nouws]

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