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.
> 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. 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.
-Hyrum
> On Mon, Nov 10, 2008 at 8:57 AM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> [second verse, same as the first...]
>>
>> Alright folks, we're branching 1.6.x this week. Here's the schedule of events:
>>
>> Nov. 12, ~1700 UTC: Create 1.6.x branch from current trunk.
>> Nov. 12, sometime in the evening: Roll 1.6.0-pre1 and get some sigs.
>> Nov. 13: release 1.6.0-pre1
>>
>> I know that we've still got some stuff in the TODO file, but it feels like it
>> isn't anything which can't happen on the branch (glasser, I haven't forgotten
>> about the FSFS stuff. :) ) Also, trunk is generally looking more stable now,
>> and by branching, we can work on stabilizing the branch independent of any
>> destabilizations going on in trunk.
>>
>> I propose that the -preN releases don't require the full signature complement,
>> and that we release them *even with known* issues, while enumerating those
>> issues as part of the release. I also propose that we use the looser voting
>> guidelines while still doing -preN releases to aid code mobility into the branch
>> (while still getting a second set of eyes on it). These changes mirror what we
>> did early in the 1.5.x release cycle.
>>
>> Objections?
>>
>> -Hyrum
>>
>>
>
Received on 2008-11-10 18:16:31 CET