This is the mail archive of the gcc@gcc.gnu.org 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 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


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