[Libreoffice] minutes of tech steering call ...
oolst at nouenoff.nl
Sat Jun 25 14:52:46 PDT 2011
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
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
>> 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.
More information about the LibreOffice