On Wed, Feb 8, 2012 at 9:17 PM, Rob Lanphier robla@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