From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H . J . Lu" To: Hans-Peter Nilsson Cc: binutils@sources.redhat.com Subject: Re: Release 2.12 Date: Thu, 25 Oct 2001 00:46:00 -0000 Message-id: <20011025004553.A18367@lucon.org> References: X-SW-Source: 2001-10/msg00483.html 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.