Re: release policy

[Ralf Wildenhues]

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

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

Agreed.

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

> >  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 :-(

OK.

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

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

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

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.

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

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

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

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

ACK.

> Making a routine time based release from that stable branch with the
> accumulated fixes is a good thing.

ACK.

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

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

Gary, it's not a specific mindset that introduces bugs.  It's broken
patches.

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

We are in violent agreement here, it seems.  :-)

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

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.

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

Sure, I understood that part.  ;)

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

Cheers,
Ralf