This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3.5 integration branch proposal
- From: Phil Edwards <phil at codesourcery dot com>
- To: Geoffrey Keating <geoffk at apple dot com>
- Cc: "'gcc at gcc dot gnu dot org'" <gcc at gcc dot gnu dot org>, Caroline Tice <ctice at apple dot com>
- Date: Fri, 9 Jan 2004 19:25:26 -0500
- Subject: Re: gcc 3.5 integration branch proposal
- References: <90200277-4301-11D8-BDBD-000A95B1F520@apple.com>
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.
--
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
- Edsger Dijkstra, 1930-2002