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
 



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to