Why not keep it on trunk and simply say "no destabilizing work. go to
a branch" ?
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?
Cheers,
-g
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
>
>
---------------------------------------------------------------------
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-10 18:05:22 CET