Re: gcc 3.5 integration branch proposal

[Phil Edwards <phil@codesourcery.com>]

On Fri, Jan 09, 2004 at 04:47:05PM -0800, Geoffrey Keating wrote:
> On 09/01/2004, at 4:25 PM, Phil Edwards wrote:
> >
> >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.

That's a tautology, not an explanation.


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

And I largely agree with you.


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

No argument there.  So, let's fix that, rather than abandon it.  If we get
"this is exactly like the trunk, except it's not THE trunk, so we don't
have to follow the rules" branches every time we're waiting to proceed
from stage 3, then something is wrong.

What if there were a harder cap on the length of time we spend in a stage?
At the end of 2 months, we push hard to go to the next stage, after
another month, if we're still not there, then too bad, we do it anyway.
The "tough love" approach to release cycles.

No, I don't know that it's a viable solution, but I'd rather try to fix the
rules we've got than just do an end run around them.  Better suggestions
solicited.


Phil

-- 
=========0=========0=========0=========0=========0=========0=========0=========0