Re: Release 2.12

["H . J . Lu" <hjl at lucon dot org>]

On Wed, Oct 24, 2001 at 09:26:54PM -0400, Hans-Peter Nilsson wrote:
> I'd like to propose H.J. as release manager for a 2.12 branch.
> Assuming that you (H.J.) are interested, and that you would
> consider doing the lot, not just GNU/Linux.
> 

Thanks for your confidence in me. But I am afraid I may not have the
time/resource to be the FSF binutils release manager, depending on the
release criteria. I have been making my binutils available to the Linux
community for a long time. However, partly because of the time/resource
constraints, I do things quite differently from the FSF binutils:

1. I don't make every release perfect. One recent example is
2.11.92.0.5 :-). A perfect release is my goal.
2. I make a new release,

	A. When the previous release is very broken, like 2.11.92.0.7
	for 2.11.92.0.5 and and 2.11.92.0.10 for 2.11.92.0.5.
	B. When the gcc/glibc development requires or can take the
	advantage of the new features in binutils.
	C. When there are enough changes accumulated in CVS. I don't
	want to have changes in CVS which are gone tested by Linux for
	a long period of time.

3. I stopped tracking branch long time ago. I want to make sure the
trunk is working for Linux.

That means my release schedule is not driven by a fixed time table, but
is done on an as-needed basis, which is defined by me. Right now, I
only test generic ELF and Linux specific features in binutils. I don't
test a.out, COFF, ECOFF, PE, .... I will make a new release even if
they are known to be broken and won't be fixed any time soon. Also I
won't make a new release just because a serious bug in a.out, COFF,
ECOFF, PE, .... is fixed.

I don't believe in updating a stable release branch. I think it is a
waste of time. My goal is to makes sure the CVS trunk won't go bad for
too long under Linux. In return, the ELF implementation in CVS trunk
is constantly checked by Linux. My scheme works ok for Linux and ELF.
But I don't think it will work too well for the FSF binutils. There are
so many questions:

1. How frequently should a FSF release be made?
2. Under what condition should a new FSF release be made?
3. How do we decide major/minor releases?
4. What is the release criteria?

Testing binutils for Linux is not easy. Testing it for all supported
platforms is a nightmare. Unless we can come to a consensus based on
my Linux binutils scheme, I don't think I am the suitable person for
the FSF binutils release manager. One possibility is

1. Turn my stable release into a release branch and fix all other
platforms on that branch.
2. In the mean time, I may be making new releases for Linux.
3. If fixing the other platforms on branch takes too long, say more
than 2 months, go to #1.
4. When there are new bugs reported after a new FSF release is made,
go to #1 if all possible, otherwise fix them on branch.


H.J.