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