Re: release policy

[Gary V. Vaughan]

Hi Ralf,

[dropping Chuck from Cc: list, as he surely reads the list and likely
 doesn't want a copy of all of this in his INBOX too...]

Ralf Wildenhues wrote:
> Hi Gary,
> 
> * Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 01:38:30PM CEST:
> 
>>Ralf Wildenhues wrote:
>>
>>>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 are missing my point completely.
> 
> My point is: Do not talk about policy.  Do not try to impose a sort of
> general policy.  Do not make promises.
> 
> (I may also be missing you point, by the way..)

No, I think we are all framing the same concerns from different points
of view.  We're talking past each other slightly, but we're talking
about the same thing :-)

>>>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...
> 
> No.  We are fighting bugs.

Bugs introduced because we piled the features in too fast before
considering what time frame we wanted to have 2.0 out in.

>>That's why I'm proposing that we move to a time based release policy!
> 
> Wrong conclusion, IMHO.  But we disagree less than it looks like.

ACK.  On both counts.

>>>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.
> 
> Yes, there is: making releases and maintaining a stable branch is work,
> and costs time.

True.  I'll concede that point :^)

> To show you how little we disagree: surely I would like to maintain,
> after 2.0.0 is released, the 2.0.x stable branch as long as necessary.
> And, time permitting, I would agree to do point releases as often as
> necessary to keep the pile of bugfixes accumulating in that branch low.
> 
> And also, at the same time, I would love to quickly release 2.2.0 after
> 2.0.0, as soon as it has seen a few new features and their subsequent
> stabilization. 
> 
> Do you see the difference here?  I am not promising anything.
> No promise of which features will be in 2.2, no timetable.

Okay.  We are in violent agreement after all.

> I don't believe that any sort of policy can be a general answer
> to the question: may a particular feature X be applied to the current
> development tree or does it need to wait until after the next release?
> I firmly believe this has to be discussed for each feature X
> individually.

Indeed.  I didn't mean to advocate that we *have* to make hard deadlines
for all our releases, just that if we had an informal policy of (say)
quarterly releases (or so), it would help to focus our minds on
impending release schedules as opposed to cool new features.

> And in fact, you can see that the 1.5.x branch has mostly been handled
> this way.  Peter put out an immediate followup release when it was
> noticed that the former was borked, otherwise releases have been more or
> less when people generally agreed upon "hmm, there's enough important
> stuff in here to warrant another stable version, is there a volunteer do
> to another point release?"  The fact that this turned about to be in
> between one week and four months is a mere observation, IMVHO.

ACK.  Tangentially, 1.5.x would have died long ago if we (I) hadn't dog
piled 2.0 so badly.

>>>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?
> 
> Well, less libtool branches may be the best way for users.

True.  Scratch that idea then.

>>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.
> 
> OK, I can agree to this, in general.  But then again I hate policy
> with hard limits (for this kind of project), see above.

Policy was a bad choice of wording on my part.  How about, guidelines,
or 'an informal aim to make 4 useful releases per year'?

>>>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.
> 
> I don't quite understand this paragraph.  Could you reformulate it?
> Thanks.

Sorry.  Sure.  I mean to say that while there is obviously a lot of work
left in the 2.0 code base just to stabilise the existing feature set, we
should not commit any new features until the list of known bugs is at
a size that is not so daunting as what we have right now.  (Despite my
earlier thoughts regarding opening HEAD to new features for a few weeks
after the release).

>>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.
> 
> See above: I don't want to have to commit on time frames.

Me neither really.  Lets just beat each other with the "but we'd like
to do 4 useful releases a year" stick if we see a danger of feature
creep! :-)

>>>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.
> 
> Gary, it's not a specific mindset that introduces bugs.  It's broken
> patches.

Ooh!  Ouch!  :-)

I mean to soy that it is easier to resist the temptation to push another
patch into the tree when a future release date is looming. Having a 'can
I stabilise this in 6 weeks along with everything else that's going on,
without slipping the next release' attitude might help give me better
focus at least.

> If you can agree on this reformulation, I'd be happy all along:
> 
> We should strive to make both regular bugfix releases of whatever stable
> release we can afford to still maintain, *and* regularly stabilize our
> development version so that new features reach users "quickly".  The
> latter may require that we do not put so many new features in the
> development tree at one time.
> 
> I can easily agree to limiting the overall amount of new features in a
> development tree.

Agreed on all counts.  I'd just like to add some sort of time frame to
maintain focus... how does an informal "we'll aim to push out 4 useful
releases per year" clause sound?

> I only saw Peter's reply after writing most of this mail, but to me it
> looks like more violent agreement.  :)

Indeed.  Big smiles all round!

Cheers,
        Gary.
-- 
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