On Tue, Jul 12, 2011 at 10:32, C. Michael Pilato <cmpil...@collab.net> wrote: >... > realize that we'd like to see the tracker sit quiet (blocker-wise) for a > week or so before saying "ship the RC", but I think we need to face some > realities: > > - blocker-class bugs can -- and will -- crop up after we branch. > > - blocker-class bugs can -- and will -- crop up after we release, > for that matter!
Right. It's a race condition, so may as well branch now. That blocker can arrive now, one millisecond before branching, or one millisecond after. >... > What to do about Serf? I'd like to think that Greg could wrap up his work > on the single remaining blocking issue in the next week or so. I've already > heard (via Hyrum) that he's essentially finished with the work, and just > testing his changes at this point. Correct. I have started outlining the test plan, but wanna get it into notes/ and flesh it out more. Then figure out how to get the conditions set up. There is a single #ifdef block that alters the logic, so we're talking a small commit/merge to get the new behavior. It is core to checkout/update/switch, which is why I've been a little careful (at this late stage). > I do not know, though, what the status > of the Serf 1.0 release is, which I *thought* was also a pre-requisite for > making available many of the recent blocker-related fixes. (Greg?) Yes. I'll do this today. We have no pending changes that I'm aware of, and consumers like svn are already adapted to the 1.0 label. >... > So, to clarify, I'm proposing the following: > > * Branch 1.7.x now. > * Release beta-1 immediately after branching. > * Make a go/no-go call on Serf 7 days from now. > * Release rc-1 after making (and acting on, if necessary) the Serf > go/no-go call. > > What say we? +1. Thanks! Cheers, -g
