This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3.5 integration branch proposal
On 09/01/2004, at 4:25 PM, Phil Edwards wrote:
On Fri, Jan 09, 2004 at 04:11:39PM -0800, Geoffrey Keating wrote:
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.
This sounds no different than the normal trunk rules, and so it
strikes me as
just a bypass of the 3-stage rules so as to not wait for 3.4. If
there's
a significant difference between these rules and the trunk rules, then
please explain what I've missed. Otherwise I object, on the grounds
that
those rules are in place for a reason, and that deliberately bypassing
them instead of helping to get 3.4 branched does more harm than good.
The significant difference is that this is not the trunk.
Yes, this branch is being created because 3.4 is taking too long. If
it was up to me, it would branch today and ship in two months exactly,
bugs or no bugs. I don't believe I ever signed up to a process where
new GCC development would be halted for months in order to meet some
arbitrary quality goal; in fact, if anyone had ever proposed that the
three-stage process should consist of an initial two-month stage 1,
then a four-month stage 2, then a six-month stage 3, I would have
objected greatly, on the grounds that such a release cycle is too long
and provides too little time for development. (You'll recall that the
original proposal was for three two-month stages; at the time, I
thought that was a fair compromise. It's a shame the compromise is not
being honoured.)