On Tue, Jul 12, 2011 at 10:32, C. Michael Pilato <cmpilato_at_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
Received on 2011-07-12 18:51:10 CEST