On Wed, Feb 8, 2012 at 9:17 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:
We're migrating to Git very soon after this
release. It would really
suck to have a huge pile of unreviewed commits going into trunk. So,
I'm going to suggest a Git migration strategy that will avoid having a
monsterous backlog. Instead of cutting over trunk at the very latest
revision, we cut over at the latest revision that is fully reviewed
and ok. Everything before the 1.19 branch point would be
grandfathered in, but everything after would need to be reviewed and
ok. So, for example, if r111000 is the branch point, and
r111000-r111020 are reviewed, but r111021 is a huge omnibus change
that sits unreviewed or fixme'd, then r111020 would be the branch
point, even if r111022-r120000 are fully reviewed. That's hopefully
an extreme example, but the goal is to make sure that trunk is always
fully reviewed.
That sounds good to me, in general terms. I hope that in practice we
can be a bit flexible so that if we could move the cutover revision up
by dozens of revisions by spending a few hours reviewing, fixing or
reverting a couple of things, we do it (for instance, if r111021 is
not a nightmare but just controversial and not too hard to revert).
What would happen to everything after the branch point
is tbd. I
haven't talked to Chad about this, but I think it's conceivable that
we can import the remainder of commits into a branch that we can
cherrypick.
That could be done, but will be hard if reviewed commits depend on
unreviewed ones. We could also just submit all post-cutoff commits
into Gerrit individually but still depending on each other. We can
then rubber-stamp the ones that were approved in CR before, and Gerrit
won't actually merge such a revision unless and until the previous
revision is approved. Submitting a long chain of dependent commits
like that should work quite nicely, *provided that none of them are
amended*: if you amend one commit, you have to rebase all of its
successors. That means that normal Gerrit review procedures wouldn't
apply to these commits and changes made to satisfy reviews would have
to be separate commits. We also couldn't rebase independent, approved
commits against master to get them merged more quickly, because that
would have the same effect.
Possibly, we could cherry-pick everything that can be cherry-picked,
and submit the other commits into Gerrit after rebasing them. That
might be more or less work than submitting everything into Gerrit,
depending on specifics.
Roan