Mark Phippard wrote:
> On Mon, Nov 10, 2008 at 11: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.
> So you would put out these pre1 etc. releases even when we know the
> tests are failing? Who would sign them? Also, who do we expect to
> consume these tarballs?
Yes. Signing of the -pre releases is not a certification that all the tests
pass, but rather an assurance that the RM hasn't screwed with the tarball. It
also gives the signers a chance to say "here are the known issues", and for
testers to tell us any that we missed. I think there is an audience for these
> I'd like to see out test suite pass, including the bindings before we
> release anything. I kind of do not think we should branch before then
> either, but that is more open for debate.
> I ran all the tests this weekend and the Perl and Ruby bindings are
> both broken. Other than that, the other test failures are "known" and
> I've seen discussion about them.
We've got to do *something*, especially if we want to release by the end of the
year. If folks are willing to let that date slip, just say so, and I'll go back
in my cave until the appropriate time. Looking back on 1.5, we didn't find a
number of issues until after we branched. The causation there could be argued,
but I think it exists, and I think there are other issues we aren't going to
find until we start pushing code out to the public in the form of prereleases
(RC or otherwise).
As I asserted elsethread, the way we are developing now, trunk will *always*
have known issues. If we wait for them to disappear, we'll never branch.
Received on 2008-11-10 19:30:02 CET