On Wed, Feb 8, 2012 at 3:43 PM, Brion Vibber <brion(a)pobox.com> wrote:
This is one of the reasons I've been hoping
we'd move to a more pre-commit
review model. Especially for big refactorings and cleanups that have
limited immediate value, we tend to get a lot of breakages a not a lot of
interest in fully reviewing them (eg actually checking all the code paths
to make sure they really work).
Here's the thinking that lead to where we are: the cutover to Git is
the point at which we want to fully move to precommit. It seems like
an enormous pain-in-the-butt to move to full precommit with our
current toolset (SVN + CodeReview tool).
However, we're much closer than we've ever been to having Git, and it
may be worth dealing with some short-term pain.
To a certain degree, I'd actually consider it
desirable to have a permanent
'slush' to the extent that destabilizing work should *always* be talked out
a bit and tested before it lands on trunk/head/master.
Yup, agree 100%.
Let's all just pretend this has always been the status quo starting
right now. I think we've already established that there used to be
more liberal reversion, and that when that went away, so too went our
ability to stay on top of the review queue.
If we're not ready to go fully git the instant we
Given that the branch just happened, and we're not ready yet, that's
the case. Chad can give you more of an update, but my understanding
* A (hopefully) final test migration of core is slated for this week.
Chad believes he's got all of the blocking problems sorted out.
* Extensions migration isn't going so smoothly. The same tools that
work splendidly with core seem to crash with the very small subset of
extensions that he's tried it out with. Could be a minor problem
that's easy to fix, or could be gawd awful. TBD
* We'd like a two-week window of warning/testing/playing around
before making the cutover.
All told, the current plan is beginning of March for core, middle of
March for extensions. More details here:
...and in the email that I hear Chad is writing :-)
we may wish
to consider applying more formal review to things proposed to go into trunk
on SVN. This may be simpler than attempting to synchronize SVN and git via
I'd be perfectly fine with either outcome (more formal pre-commit
review, or picking our SVN->Git cutover point based on what's