[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: release policy

From: Ralf Wildenhues
Subject: Re: release policy
Date: Sun, 18 Sep 2005 15:46:59 +0200

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

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

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.

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

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]