Re: release policy

[Gary V. Vaughan]

Ralf Wildenhues wrote:
> Hi Gary,

Hallo Ralf,

> * Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 11:30:32AM CEST:
> 
>>I propose that we move from a feature driven release policy to a time
>>based one.  After 2.0, we should aim for a stable release (say) every
>>3 months, with a feature freeze in the last six weeks.  To maintain
>>forwards momentum, and prevent another embarrassing 2.0 like debacle,
>>I think that every second one of those should come from HEAD.  I think
>>that as long as we forward port bug fixes from the last release branch
>>as they are applied, we should only need to maintain 2 branches at
>>once.
>>
>>So in the future, assuming we start the process next year, our release
>>schedule should look something like this (not taking into account
>>public holidays and slipping to the nearest weekend):
>>
> 
> *snip*
> 
>>We can always choose to stick with a troublesome stable branch for
>>longer if it turns out to need more work to iron out any bugs and
>>regressions rather than ploughing on with another head release...
>>thoughts?
> 
> 
> Yes, just one: this is INSANE.
> 
> Gary, haven't you burnt yourself enough with promising releases at
> certain times?

This is because we are locked in a feature based release policy.  I
think moving to a time based policy will make this problem redundant.

> You talked about 2.0 being close more than a year ago, it's not out.

Agreed.  And the fault there was piling in more features without
stabilising the existing ones.

> A few weeks ago you talk about it being possible in about two weeks,
> yet today I see patches with large "necessary" changes.

We're still fighting with that feature based release...

>  Have you
> ever thought that, before a release, things should get quieter, less
> intrusive, and not the other way round?  And that promises not kept
> reflect badly?

All the time :-(  That's why I'm proposing that we move to a time
based release policy!

> Also, my time investment in Libtool is not sustainable at the current
> amount.  I see others coming and leaving as well.  With this, any kind
> of deadline promises is just fooling oneself and making this project
> look very bad.

Nor mine.  And I agree that much work needs to be done in stabilising
before we add any new features.  During that time (and beyond if we
keep the release times in mind when adding a feature), there is nothing
to stop us putting out timely quarterly releases which will be more
stable than the last.

> And regarding forward momentum: if you need a playground to put un-
> finished ideas in that later turn out to be unfixable or need large
> intrusive fixes: this is not the way to go for a project other ones
> depend upon in order to function!  Not at all!

ACK.  Feature branches may be the right way to do this in future?

My point about forward momentum was that if we only open the tree
for new features for a few weeks after a release, and spend the
rest of the time stabilising the code base with the aim of making
quarterly releases things should continue to improve.  Doing half
yearly or annual releases would be worse IMHO because there will be
the temptation to dog pile features again.

> If you really think someone could commit on maintaining more than one
> branch at a time, I would like to see some commitment on this.  I for
> one am not paid to do any work on Libtool.  And there are still lots
> of bug reports (against branch-1-5 as well as HEAD!) open and
> unfinished, for real issues with libtool that other people care about.

Sure, so we have a moratorium on new features *entirely* for future
time based releases until all of this is under control.  That seems
much more sane to me than continuing as we have.

My argument for 2 branches is that bugs will be reported against the
most recent stable release as often as not, and fixing them there
and forward porting seems to be the right approach.  Making a routine
time based release from that stable branch with the accumulated fixes
is a good thing.  Notice that in my proposal we make an alpha from
the trunk at the same time as a maintenance release from the stable
branch, and then spend the next quarter stabilising the alpha before
it becomes promoting to stable twice a year... effectively each branch
lives for one year.  3 months in alpha, 3 months as an unstable release
while the previous stable branch is maintained, 3 months as a stable
release while the new features can be added on the trunk and 3 months
as a maintenance release.   I'm not hellbent on quarterly releases
at all, it just seems like a reasonable time period and the symmetry
is pleasant and requires only 2 branches.

> I do not mind the goal of frequent releases at all, I just won't commit
> to any kind of timetable, and, more importantly, I won't commit to
> releasing from a yet unknown "development tree" with whatever broken
> features.

Agreed, but that is still a feature based mindset.  Broken features can
only be added in the first half of the first quarter of a branch's
life cycle, and should be satisfactorily stabilised before adding
anything else new.  The implication is that even after 2.0, we need
to focus on stabilisation... but that shouldn't prevent us from making
quarterly releases that are each better than the previous one!

> Forwards momentum is not gained by policy or talk, it's
> gained by commitment, and as the result of work being done.  And _then_,
> the achieved work can act as a natural good measure of when it is useful
> to have a new release.

And yet that mindset has made us put so much stuff into the 2.0 release
that we haven't been able to stabilise it fast enough to release.

However, I do take your point: it WOULD be insane to push any release
out when we know it has serious bugs in it, and we certainly shouldn't
fall prey to that.

Ignore the dates from my other mail, and even the quarterly schedule if
you wish... I think we should discuss the merits of moving to time based
releases with an eye towards preventing feature creep in the future.

Cheers,
        Gary.

P.S. I do realise that this thread is controversial and inflammatory,
     but it is certainly not my intention to upset anyone, just to
     fuel discussion about exploring a better way to handle releases
     in the future.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature