Hyrum K. Wright wrote:
> Greg Stein wrote:
>
>> Why not keep it on trunk and simply say "no destabilizing work. go to
>> a branch" ?
>>
>
> Mainly because I don't trust people (myself included) to follow that mandate.
>
Sounds like a case of "pull commit privileges" to me then. Sorry to be
blunt, but throwing code over one's shoulder should not be tolerated.
>> Once you branch, then you'll get less traffic on it. And branching
>> with *known* work simply screams "too early" to me. I mean... if we
>> know it isn't good enough for 1.6, then why branch and pretend it is?
>>
>
> I'm tired of playing bug whack-a-mole on trunk while waiting to branch.
>
> I think we've gotten to the point were we have a number of different features in
> various stages of development. That's great, but it also introduces problems,
> one of which is that trunk is generally a bit more unstable these days than it
> has been in the past.
Say what? If trunk is unstable, that's clearly in violation of the
policies that we set down on day 1 and someone needs a big stick applied
to their pants.
> Rather than waiting for the stars to align and trunk to
> get stable, let's branch and start stabilizing a known feature set on the
> branch, instead of a moving target on trunk.
>
I disagree. If the trunk is unstable, branch it off to some safe
location and revert the changes that destabilized it. There is *never*
*any* excuse for destabilizing trunk with new features for longer than
the day or so it usually takes to figure out something's gone wrong. If
a feature isn't in a stable-enough state (i.e., if it knowingly breaks
other stuff even when disabled), it has no place on trunk.
I'm very disappointed that things have been allowed to deteriorate to
this state.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-11 16:05:13 CET