[Libreoffice] minutes of tech steering call ...

[Cor Nouws]

Hi Michael,

Michael Meeks wrote (24-06-11 10:52)

> 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 ;-)

Don't worry - we're not going to forget you :-p

>> 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.

Sure, sure.

> 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.

What we do know (1+1=2), is that if there is a limited amount of people 
doing QA, providing them more time (weeks) will result in more testing.

> Much QA seems to be deferred to post release - when it seems
> most people really start testing ;-).

It looks like. And also is true for some part.
Therefore the step to make it possible to install betas alongside the 
stable version, is a major improvement of our work flow.

> 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.

I agree with the merits of that approach.
Don't know however if that alone will make more people do QA. Serious 
testing and reporting are time-consuming. So starting again with a fresh 
version every few weeks, costs time...

> 	Indeed - by freezing earlier we could potentially make things worse ;-)

Warning: you're going to loose me completely in the next paragraph.

> 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 ...

Do misunderstand the meaning of 'freezing'? I understand it as the point 
from where only bug fixes are allowed to the branch.
So a longer time frame without large clean-up, re-factoring, other smart 
improvements and new features. Definitely this gives more time to find 
and fix bugs.
The more QA, people, the faster it goes, of course. But that is another 
matter.
And of course, QA has to be a continuous state. So a possible longer 
time from freeze to release, would IMO not mean that we advise people to 
start later with testing :-)

Any change that the time from freeze to release can be too long, and 
thus a waste of developer time? I can hardly imagine: if less time is 
needed for fixing bugs, more time is left for major work on the master.

> 	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.

OK, half October .. till December 5 is only 7 weeks.
Deciding at that moment, holds the risk that developers suddenly have 
say only 3 or 4 weeks left for finishing major work, in stead of 7.
IMO, that is not fair.

Though of course the venue to discuss it, is excellent (which is not yet 
a promise from my side that I will be there..)
But still, I would very much prefer to keep an eye on all that is 
related the next months, and see if we can discuss this on list, during 
a conf. call, somewhere the next months.
Then we can pick up the essentials from my previous mail too: the 
reasons to be on the very safe side now.

> 	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/

Still, having a meeting discussing with people at the table how we go 
forward with all the stuff, is a great opportunity.
OK?

Cheers,

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