[Libreoffice] minutes of tech steering call ...

[Cor Nouws]

Hi Norbert, *,

Norbert Thiebaud wrote (25-06-11 02:21)
> On Fri, Jun 24, 2011 at 6:00 PM, Cor Nouws<oolst at nouenoff.nl>  wrote:

>> 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.
>
> Well true except that it freeze _that_ branch... but it does not
> _force_ people to stop working on master.
>
> So what I understand Michael saying is:
>
> 1/ you freeze and create the 3.X branch
> 2/ little test is done on 3.X branch for the reasons aforementioned

  IMO that is a crucial effect to *avoid*.
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 :-)

> [...]

( Now I snip a whole lot of words from you with valuable aspects of 
QA<>developmet etc.
I expect much of it will be used either by improving the process over 
time, or by establishing the topics needed at a certain moment for 
judging/choosing what is the best time-set for 3.5.0. )


>> 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 :-)
>
> Then the question is How would 'freezing' improve that (motivate
> poeple to do early testing)

Not earlier compared to the moment of freezing. But earlier compared to 
the moment of releasing. Thus more time available for that specific 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.
>
> Changing the freeze date has no impact what-so-ever on the amount of
> bug or the time it takes to fix them...
> I must be missing your point here...

Hmm, it looks as if I tried to answer a non-existing question.

>> 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.
>
> That is the 'norm'... the point of continuous dev is that everyday
> could be release day... but since we release fairly often the
> consequence of not being ready for a given release is not that dire...
>
> 'Major work' is typically done in a feature-branch.. and that feature
> branch is merged when it is ready not when the schedule say so. The
> whole idea behind 'time-based-released' is that you release what is
> ready at the time you've chosen. not cram the development to squeeze
> it in time....

Yes, that is clear and sounds sane.
However, as developer you look at the calendar too, and will sometimes 
make some estimates about what you can/would like to do, in order to get 
a major work done for a minor release. Therefore I argue that it would 
not be fair to decide on 7 weeks from the deadline, that it is shortened 
by 3 or 4 weeks.

Regards,

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