Re: change for configuring on FreeBSD

[Geoff Keating <geoffk at cygnus dot com>]

> Date: Sun, 14 May 2000 11:54:36 -0700
> From: "David O'Brien" <obrien@FreeBSD.org>

> On Sun, May 14, 2000 at 11:38:02AM -0700, H . J . Lu wrote:
> > I simply don't have the time to work on 2.10. Unless 2.10 has all
> > the patches in the main trunk I like, I don't think I can do anything
> > about it.
> 
> IMHO, this shows a weakness in the Binutils release cycle stratagy.
> 
> Branching and then polishing for a .0 release has never worked for
> FreeBSD.  Instead near a .0 release, we enter a code slush in which only
> things that fix bugs and thing that don't stability can be committed.
> Then a code freeze is entered.  The gets all the developers to put their
> energy into the release.  I wonder how many of the Binutils developers
> are not putting any time into the 2.10 release due to this.

As a practical matter, unfortunately, most binutils developers are
working on a schedule based on Cygnus or Linux releases, not the 2.10
release, so a code freeze would just mean that they would queue their
patches until the freeze went away.

HJ's releases, of course, are a separate problem which is that HJ
doesn't seem to consider it worthwhile to merge his fork with the
mainline.

> The current method also means that things added during the slush/freeze
> peroid make it into the release.  There has been 2 months of development
> since the 2.10 branch was created -- that's 2 months of fixes and
> features.

Would you really consider, for instance, a new ia64 port, a radical
overhaul of the powerpc-elf linker scripts, and an XCOFF64 port to be
suitable things for a checkin during a code freeze?

The best solution to this problem is to simply release more frequently
so that (a) there is no need for a two-month period between cutting a
branch and making a release and (b) a new feature is in a release
within a reasonable time of it being added to CVS.

-- 
- Geoffrey Keating <geoffk@cygnus.com>