Re: GNU make: Next release schedule.

[Paul Smith]

On Thu, 2009-09-17 at 09:52 +0200, Boris Kolpackov wrote:
> I will try my best to meet the 1 Oct deadline thought it is a tall 
> order to try to find time to work on all this in 13 days. Can we maybe
> extend it to Oct 15?

Sure, if there's activity that's going on I won't cut it off to meet an
arbitrary deadline.

My thinking on this is that the current release of GNU make has all
these issues, and even more serious ones that have been fixed since, for
the last 3.5+ years and people are managing OK with them.  Unless these
things are regressions that appear only in the CVS version, even a
not-fully-fixed release will be better than what's available today.

What I was hoping to do by committing to a more regular release cycle
was take the pressure off a bit.  If you know you can get it fixed in a
few months, rather than waiting 2 or more years, it makes a big
difference in what you feel you have to accomplish before the release.

However, again if things are getting fixed I don't want to cut it short.

> > I'll create a release tarball and announce it in the usual places, 
> > and give until Oct 15 for people to test it out. 
> 
> I think this is too little time. Our best bet in uncovering serious bugs
> are distributions like Debian, Fedora, etc. For them to package and
> upload make and then re-build a significant portion of the repository
> in 15 days is unrealistic (i.e., there won't be many new versions of
> the packages in this time frame that would trigger rebuilds). I would
> say a couple of months would be a good bet. After all, we have already
> waited a couple of years ;-). 

Possibly.  On the other hand there's nothing to say that those
distributions have to take the new version of make; they could wait a
release cycle even after we release it, especially if there are
problems.  I do have a collection of free software that I build with GNU
make, that I plan to test with.  Obviously this is a somewhat arbitrary
and self-selecting test suite :-).

My experience says that no matter how long you leave a package in
"release candidate" mode, most folks won't pick it up and try it until
it's actually released.  There's definitely a rapidly diminishing return
scenario to pre-releases.

> > I'll also be instituting regular, time-based releases. Probably every 6
> > months but maybe more often if activity warrants it. 
> 
> I may be in the minority here but I believe for a critical tool like
> GNU make releasing very often is not going to bring much benefit. I
> would say 1 year cycle (10 months development and 2 months beta testing)
> for the "new features" releases sounds good. We can make bug-fix-only
> releases as required.

As I wrote this I was wondering about that myself.  My main concern is
that bug fixes are not getting out there fast enough, combined with the
comment I made above: if you only release every once in a great while,
the pressure to do everything before you release is very great... which
just defers things even further.  This is exactly what happened with the
Linux 2.5.x stream and many other open source projects we can all name.
In free software project management circles the solution to this issue
seems pretty clear now: release early and often.

However, I do agree that new features rolling out every few months is
not necessarily a benefit for a tool like make.  As much as the lack of
bug fixing is frustrating I do believe that most people USING the tool
enjoy the stability and not having to worry so much about
backward-compatibility and which version supports which features and
getting the right version on the system.  Obviously if it's YOUR pet
feature that isn't available it's frustrating :-)

So, maybe we could have more timely releases for bug fixes and bunch up
features into yearly or so releases, as you suggest.  This might
necessitate a change in versioning scheme for GNU make.  Maybe these
larger releases would have a bump of the major number, while the bug
fixes would bump the minor number.  I don't think a tool as simple as
make really requires a three level version number scheme.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist