From mboxrd@z Thu Jan  1 00:00:00 1970
From: Geoff Keating <geoffk@geoffk.org>
To: gcc@gcc.gnu.org
Subject: Re: Compiler for Red Hat Linux 8
Date: Wed, 18 Jul 2001 14:33:00 -0000
Message-id: <200107182149.OAA10449@geoffk.org>
X-SW-Source: 2001-07/msg01305.html

A general tone of the responses so far has been "why can't you use a
FSF released compiler without modification?"

I don't think this will be possible.

1. We don't have a process for supporting a compiler that doesn't come
   out of our internal tree.  We would want to be able to do things
   like commit patches to the branch as we send them to customers.  I
   don't think we'd be able to do this on a FSF release branch.
   What's more, we might need to ship a new compiler to a customer
   with a patch, which would imply making a new release if we are to
   use only released versions.

2. We have fixed deadlines and requirements for the compiler that are
   unlikely to be matched by a FSF release process.  For instance,
   suppose that the compiler is broken on mips-linux at the point when
   the branch is frozen for testing by release engineering.  At that
   point, this means that the release will be broken on mips-linux.
   We don't mind, because we aren't doing a MIPS release, but the SC
   might; but we can't change our schedules because of it, which means
   the release has to go out anyway.  The issue of the subreg_byte
   patch has already been raised.  It also means that we might have to
   block patches that could make the release less stable on the
   platforms we care about, which are only a small subset of the
   platforms that GCC 3.0 supports.

3. It's likely that our releng people would need to be in control of
   the release process.  This is likely to be politically difficult.
   It's probably also not something Red Hat wants to do; we spent a
   lot of time trying to convince people that the GCC development
   process was independent and not "controlled by Red Hat", but for
   this we need the control.  

   We also don't have a releng process for making releases out of a
   branch of the FSF tree.  We're already doing something new---this
   release will be in RPMs, not the usual tclish installer---and it's
   hard to do many new things at once.

4. It's possible that, depending on how the IA64 situation goes, we
   might have to have code in the compiler which no-one outside Red
   Hat (and not on the appropriate NDA) can see until some point
   shortly before the release.  I'm not sure how that could be made to
   work.

5. We would prefer to ship a newer compiler than something off the 3.0
   branch.   By the time that this release goes out, the 3.0 branch
   will be over a year old.  You'll note that RHL 7.2 is not out yet,
   and on the normal schedule RHL 8 will be about six months later.

In short, GCC developers wouldn't like it, Red Hat wouldn't like it,
the FSF and the SC wouldn't like it, and it's a recipe for disaster.
This is why I didn't even suggest it in my original mail.

A number of the above points apply even if we are taking a FSF release
and patching it.  It's also questionable what benefit doing this has
over using our internal tree; you end up with a situation like that of
the kernel, where it is technically based off a release but it has
around 400 patches applied.

-- 
- Geoffrey Keating <geoffk@geoffk.org>