This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Release 2.12


On Thu, Oct 25, 2001 at 08:57:16AM -0700, David O'Brien wrote:
> On Thu, Oct 25, 2001 at 12:45:53AM -0700, H . J . Lu wrote:
> > 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?
> 
> FreeBSD has been happy with the release schedule 2.10.0 and later.
> We are just to the point that a lot of changes have happened in the
> main-line, including new important architecture support (ia-64, x64_64), so
> it is time for a new major release.  If it weren't for those two new
> arches, FreeBSD would be fine with 2.11.2.  (I know someone will say both
> of these arches are in 2_11, but they are so new lots of changes are
> being made for them and not getting put into the 2_11 branch.)

I have been never happy with the FSF release schedule. Otherwise, I might
not have been making my own binutils. The main problem is there is never
a stable, capable binutils for Linux. Even today, we are still working on
some new ELF features. I guess they will only be tested on Linux :-(.

> 
> > 2. Under what condition should a new FSF release be made?
> 
> As with p0rn, we may not be able to exactly define it, but we can pretty
> much "feel" when it is time.  As we've seen this week everyone "feels" it
> is time.

Well, by "we", did you mean the release manager or the users?

> 
> 
> > 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.
> 
> You personally do not have to do the testing on each and ever platform.

I did mean I would test it personally. It is just simply a nightmare to
get it tested on all supported platforms at all.

> You are "just" the gatekeeper. (it is a big job, thus the "just")
> >From your maintenance of your Linux Binutils you can gauge the risk of
> changes.  This is the desired quality you bring to being the release
> manager.

I managed to make those risks under control because my release focuses on
Linux only and I tried not to make changes to binutils from as much as I
could. To have a realistic release,

1. W should have a list of primary supported targets. There must be enough
developers and users for such targets so that bugs can be reported and
fixed quickly. By "users", I mean the people who are willing to test
a new binutils thoroughly on their machines on a very frequent basis.
2. Except for the configure scripts, primary targets should be CPU/ABI,
not CPU/OS if all possible. That means we should make binutils generic
to CPU/ABI as much as we can get away with it.
3. All developers should configure their binutils with

# .../configure --enable-targets=all --enable-64-bit-bfd
and
# .../configure --enable-shared

They should always do

# make check

and make sure everything passes for their targets.

4. The release schedule should be dictated by primary targets.
5. We should keep none primary targets up to date. But we may or may not
make releases for none primary targets. It is totally left to discretion
of the release manager.



H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]