On Tue, Mar 22, 2011 at 5:27 PM, Happy-melon <happy-me...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
