I think Roan hits it on the nose. Most of the problems Ashar and Neil raise are flaws in our code review process, not flaws in the tools we use *to do* code review. I actually think that CodeReview works quite well, **for the system we currently use**. I think many of us agree that, one way or another, *that system* has major flaws.
The fact that one discussion has quickly fragmented into fresh threads on *all* of the 'big three' (code review workflow, VCS, and release cycle) illustrates how intimately connected all these things are. It makes no sense to choose a VCS which doesn't support our code review workflow; if our code review is worthless if it does not support a coherent release cycle; and the release workflow (and the to-freeze-or-not-to-freeze question) has a dependency on the VCS infrastructure.
Ultimately, though, it's a mistake to think of any of these issues as technical questions: they are **social** problems. We have to choose the *mindset* which works for us as individuals, as a group and as a charitable Foundation. Currently our development mindset is of the Wild West: pretty much everyone works alone, on things which either interest them or which they are being paid to be interested in, and while everyone is responsible enough to fix their own bugs, our focus is on whatever we, individually, are doing rather than the finished product, because the product only *becomes* finished once every 6 months or so. The only reasons now that we keep trunk broadly runnable are a) it makes it easier for us to continue our own development, and b) the TWN people shout at us whenever we break it.
I'm not, let me be clear, saying that said 'Wild West' mindset is at all a bad thing, it is very open and inclusive and it keeps us from the endless trivial discussions which lead to cynicism and then flames in more close-knit communities. But as Roan says, it is *not* the only mindset, and the alternative is one which is more focussed at every stage on how changes affect a continuously-finished product. We know the regime which is at the other end of the scale: the Linux kernel's universal pre-commit review, which I'm going to suggest we call the 'Burnt Offering' approach to coding as patches are worked, reworked, and inevitably reduced in number before being presented for divine approval. That has clear advantages, in ensuring very high code quality and probably improving *everyone's* coding skills, but also the disadvantages Roan mentions.
The smoketest-trunk-every-week development model, which defies being given a crass analogy, is somewhere in the middle, and I think that's closer to where we need to be. If we made an absolute policy of scapping to the WMF cluster once a week, every week, it would force a shift in our mindset (arguably a shift *back*), but not one that's seen as an artificial limitation. No one will begrudge a release manager reverting changes on Tuesday afternoon which people agree will not be fixed in time for a Wednesday scap, while the same release manager spending Tuesday *not* merging changes for the exact same reason is seen in a much more negative light. We retain people's ability to make rapid and immediate changes to a bleeding-edge trunk, but still ensure that we do not get carried away, as we did for 1.17 and are still merrily doing for 1.18, on a tide of editing which is not particularly focussed or managed (witness the fact that out of the 15,000 revisions in 1.17, we can point out only about three 'headline' features).
There are implementation questions to follow on from whichever workflow regime we move towards: for the weekly-scap process we need to find a replacement for Brion and his cluebat which is as reliable and efficient as he was; for a Linux-style system we need to sort out how to ensure that patches get the review that they need and that it doesn't just kill our development stone dead; and even to continue in the Wild West we need to sort out how to stop traceing out the Himlayas with the graph of unreviewed commits and actually get our damn releases out to prove that the system can work. My main point is that *any* technical discussion, about SVN/Git, about CodeReview or its alternatives, even about Bugzilla/Redmine, is premature unless we have reached an adequate conclusion about the social aspects of this combined issue. Because Git does not write code, nor does CodeReview or Bugzilla. *We* write MediaWiki, and we could in principle do it in notepad or pico if we wanted (some of us probably do :-D). The most important question is what will make us, as a group, more effective at writing cool software. Answers on a postcard.
--HM