Re: gcc 3.5 integration branch proposal

[Geoff Keating <geoffk at apple dot com>]

On Jan 12, 2004, at 3:49 PM, Mark Mitchell wrote:

> On Mon, 2004-01-12 at 15:42, Geoff Keating wrote:
> > On Jan 12, 2004, at 11:22 AM, Mark Mitchell wrote:
> >
> > > I'll make you a deal -- if you will commit to fixing five Bugzilla
> > > regressions between now and January 31st, and five more after the
> > > branch
> > > is made, then I'll create the branch on January 31st, come hell or 
> > > high
> > > water.  Deal?
> >
> > I think January 31 would be too long to wait, sorry.
>
> No counter-offer? :-)

I was going to, but it would have started with "Well, how about you 
create a branch two weeks ago, and then..."  :-)

> By the way, there's no question that there will be chaos when we 
> finally
> do branch, and everyone starts putting stuff in for 3.5.  That's
> actually what's supposed to happen in Stage 1. :-)

No, I don't think that is what's supposed to happen in Stage 1.  I 
certainly don't remember the word 'chaos' being used.

> I completely agree with Phil, however, that creating a proxy-mainline 
> is
> inappropriate.

I think that the release manager holding up GCC development for months 
in order to achieve an arbitrary regression goal is inappropriate, 
especially if this comes at the cost of other goals (most notably, 
timeliness) of one or more releases.  In particular, I think that your 
excessive focus on avoiding regressions is contributing to GCC's 
serious problems in other areas, most notably speed of compilation and 
speed of generated code when compared against the best available 
commercial compilers (for me, that's CodeWarrior and icc/xlc 
respectively, and we're about 60% and 25% behind respectively).

Just to remind you, here is a quote from our web pages:

> Although maintaining a development branch, including merging new 
> changes from the mainline, is somewhat burdensome, the absolute worst 
> case is that such a branch will have to be maintained for four months. 
> During two of those months, the only mainline changes will be 
> bug-fixes, so it is unlikely that many conflicts will occur.

Here's another one:

> We think that we will better serve the user community by making 
> releases somewhat more frequently, and on a consistent schedule.

I do not believe we are achieving this aim.

> Apple (and some other vendors, including CodeSourcery) is in the
> position of doing its own release management and bug-fixing based on
> various versions of GCC.  Therefore, having high-quality FSF releases
> may not make much of a difference to Apple; Apple doesn't use it
> directly anyhow.  (Of course I do not know what Apple's management 
> wants
> in this respect, nor do I know what your personal motivations might be,
> independently of your Apple employeeship.)

Apple would like to use FSF releases.  Unfortunately, a prerequisite 
for this is that the FSF actually makes releases in a timely fashion, 
and this is not happening.

> These releases, however, are FSF releases, and they should be of the
> same high quality as the FSF releases for other packages, such as Emacs
> or GNU Awk.  Unless the SC says otherwise, of course. :-)

So, why do you think the current mainline is not "high quality"?

--
Geoff Keating <geoffk@apple.com>