On Tue, Mar 22, 2011 at 5:27 PM, Happy-melon happy-melon@live.com wrote:
To my mind, this is one of the most important points. We have built up a very comprehensive infrastructure for code review in SVN, and there is a lot of manhours behind that work; and just as many hours associated with setting up a replacement system for git. Who is going to put that infrastructure in place, in amongst all the many other priorities we have at the moment? Moving to a VCS which makes it "easier to review stuff" **in principle** is going to be of no use whatsoever if it sends the **practical implementation** of that review process back to the stone age.
I've been thinking about this problem quite a bit, and I agree that it's a large problem. However, one thing that I think is very important for us to keep in mind. Let's say that we were starting from scratch building a new project, and we had, on the one hand Subversion+Code Review, and on the other Git+some other alternative. I'm going to bet that most people would recommend Git+some other alternative. Our code review tool is pretty nice, but we can't let it be the tail that wags the dog.
If our code review system was working smoothly, I wouldn't mind delaying this. However, it's pretty clear that code reviews aren't keeping pace (be sure to look at revisions marked "new" in trunk): http://toolserver.org/~robla/crstats/crstats.trunkall.html
I believe that once the reviewers get the hang of Git, they'll be more efficient, and be more capable of keeping up. I think paired with Neil's proposal[1] that we switch to pre-commit reviews, and we might actually be able to get back on a regular release cycle.
Rob
[1] Neils proposal: http://lists.wikimedia.org/pipermail/wikitech-l/2011-March/052037.html