Re: release policy

[Ralf Wildenhues]

Hi Gary, 

Gary V. Vaughan writes:
> [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...]

Whooops.  Sorry for overlooking that.  Hope he has dupes turned off.. 

> Ralf Wildenhues wrote:
> > * Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 01:38:30PM CEST:

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

OK. 

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

Yes, one reason.  I'll give you another possible one:
bugs piling up because we were too busy introducing shiny new features
and ignoring bug reports, user complaints, and other signs of general
brokennes. 

And another possible one:
bugs piling up because we were not scrutinizing new patches enough. 

Can you tell that at least I *try* to improve on the latter? 

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

I believe the list of open issues has already had a positive effect of
*increasing awareness* about the them. 

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

Exactly. 

> > > 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'?

How about a guideline to only put stuff in the tree that actually has a
chance of working for more than one kind of user?  How about a guideline
to just keep HEAD stable enough to be usable all the time?  Nobody'd care
whether you make one or four releases per year then. 

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

This notion sounds good to me.  Although again, I would not make hard
rules.  If you have a new feature that is easy to overlook, easy to verify
that it should work and not break anything else, I do not mind admitting
it right after 2.0. 

For example, I regard Fortran 90 support as such a feature (although the
tests make "make dist" not work without a Fortran 90 compiler). 

Similarly, I regard support for new systems that way, iff changes can be
shown not to affect other system's adversely. 

> > 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! :-)

Hmm. 

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

OK.  I'll try to beat you with the 'can I stabilize this patch before
putting it in CVS at all' clue stick then. 

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

How does "we'll aim to keep HEAD releasable at all times; and whenever we
realize it's not, we try to fix that" sound?  As a consequence: "we try to
introduce new features only in a least-interdepending way"? 

I realize that in this post I may be beating dying horses, but I really
want to make sure my point gets there.  ;-) 

Cheers,
Ralf