This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc 3.5 integration branch proposal

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
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

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 <>

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