gcc 3.5 integration branch proposal

[Geoffrey Keating <geoffk at apple dot com>]

It looks like it's going to be quite some time before 3.4 branches and 
the mainline is opened up for general work.  There are also a number of 
projects which are completed, or partially completed, and are waiting 
in branches and in people's private trees for 3.5 to open up to be 
committed.  This has a number of bad effects:

1. People are having to maintain their own patches and/or branches and 
keep them up-to-date.
2. These patches and branches are not getting as much testing as they 
might, because the available testing effort is being spread over many 
places.
3. These patches and branches are not being tested with each other.

I am concerned that this will cause great instability in the initial 
development of GCC 3.5, and will lead to delays in the release of GCC 
3.5.  I therefore propose to create a gcc-3.5-integration-branch.  It 
will be similar in some ways to the 'basic-improvement' branch in the 
GCC 3.4 timeframe, but will have some significant differences.  The 
proposed rules for the branch are:

1. This branch is for fully-tested, approved patches.  The rules for 
committing to it are the same as the rules that apply during Stage 1 of 
GCC development.  Experimental or incomplete work should not be put on 
the branch.
2. The intention is that immediately after GCC 3.4 branches, this 
branch will be merged back to mainline.
3. I will be making regular (probably weekly) merges from mainline onto 
this branch.  I will be testing these merges with a powerpc-darwin 
native bootstrap.  Anyone who commits anything to the branch that can't 
be fully tested with a powerpc-darwin native bootstrap should watch for 
the mail I send out saying the merge is done, and then run a test on 
their own platform and send the results to gcc-testresults.
4. Anyone who commits to the branch is still responsible for 
maintaining the patch on the branch: fixing regressions that it causes, 
and sometimes updating or reintegrating it after merges.  I expect that 
for most patches, this will be much less work than maintaining the 
patch on their own.
5. I may back a patch out of the branch if it (a) causes bootstrap 
failure or significant regressions on any platform and the author 
doesn't appear to be able to fix it quickly, or (b) don't appear to 
have followed Rule 1 or Rule 3.

Any objections to this proposal?  If not, I'll create the branch in the 
next few days.