[Libreoffice] minutes of tech steering call ...

[Michael Meeks]

Hi Cor,

On Fri, 2011-06-24 at 01:09 +0200, Cor Nouws wrote:
> Apologies for that - but it was about what I expected. (Have to try to 
> focus on making a living during the day-hours ;-) )

	Sure, sure ...

> > 	+ extend the feature-freeze period for 3.5 ?
> > 		+ Norbert: may not help people fix things, just move
> > 		  their work to the next generation.
..
> Thanks for discussing the subject and the ideas brought forward.

	Hey - I'm only sorry that there was no-one there to argue the other
point of view ;-)

> On the other hand, we do not yet know how
>   - the time of the year (Christmas, Western New year);
>   - the speed of the growth of people involved in QA;
>   - the fact that QA-time has to be devided among various versions 
> simultaneously,
>   - etc,
> will affect the reality in 6 months from now :-)

	Of course; predicting the future is hard.

> Plus - especially with the unfortunate experience from 3.4.0, and to do 
> something good for users, testers, marketing etc - IMO it is better that 
> in the end we have three weeks extra, than that we lack three days.
> So I would really love to be on the save side ..

	So - the problem is, there is really no safe side, it is a balance.
There is no guarantee that people will work more on bug-fixing if we
feature freeze earlier, nor is there a guarantee that people will do QA
and find the bugs until we are in the late RC phase no matter how early
we release. Much QA seems to be deferred to post release - when it seems
most people really start testing ;-). So this is some sort of
psychological game, which (I hope) we already play quite well by
releasing and then doing lots of iterative incremental improved
versions.

	Indeed - by freezing earlier we could potentially make things worse ;-)
because QA will not have started at all, and thus there will apparently
be no bugs to fix, and hackers will then get really stuck into working
on another branch, which will diverge far more from the code we're
releasing, such that they have less interest / ability to fix bugs in
the stable version by the time QA arrives in earnest so ...

	So, this all needs to be discussed explained; that is best done in
person I think.

> However, we do not have to decide that exactly right now, do we?!

	Quite. So - what I think we should do is to propose a joint talk on the
topic at the LibreOffice conference in Paris in October - preferably
with some good assessment of the quality of master at that time; then we
can decide whether to move the existing (December) freeze date forward
or back at our leisure - and over beer.

	How does that sound ? any chance you could recruit a suitable panel ?
I'd want Caolan, Petr, myself and Bjoern on it - and yourself, Rainer,
and whomever else you can choose that is actively working on QA / etc.
Any chance you can bash off a web-form submissions at:

	http://conference.libreoffice.org/submit-your-paper/

	Thanks,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot