On Friday 31 October 2008 6:21:55 pm David Sterratt wrote:
On Thu, 2008-10-30 at 11:07 -0400, Darren Oh wrote:
There are four bottlenecks in project maintenance:
1. People who complain outnumber people to read complaints. 2. People who read complaints outnumber people who provide patches. 3. People who provide patches outnumber people who review patches. 4. People who review patches outnumber people who commit patches.
A thought about widening bottleneck #3 that requires no technological innovation: Suppose I've submitted a patch that I'm keen to see reviewed and committed. Would it be socially acceptable to review two other patches (preferably related in some way and of a similar level of complexity) and ask the submitters of those patches to review my patch in return?
You scratch my patch, I'll scratch yours.
Although there would be no guarantee of my patch being reviewed by the other patch submitters, the fact that it might happen would give me more motivation to review patches.
Such a thing already happens from time to time informally in IRC, especially between active "known" developers. It would probably be a bit gauche to try to do so in the issue queue directly, but "review swapping" via IRC is already common and could probably stand to become more so. The underlying problem I see is that in the case of many many patches, most people are simply not qualified to give a decent review. The amazing work that has gone into the automated testing server and simpletest module recently has, ironically, removed one of the main places where "random members of the crowd" can offer useful feedback; that is, "does this break stuff?" Coding style reviews most people can do if they're picky enough (and if you're not, then you should be), but substantive reviews of non-trivial patches requires a knowledge of the system being modified, whether it's a bug or a feature request. That's why the few people who seem to be able to intelligently review patches all over the system (and have time to do so) are worth their weight in gold. I've actually felt for some time that Drupal has reached a size and complexity where we need a more tiered maintainer system. Right now, Dries and Angie are the maintainers for D7, and based on the length of the recent-commit log[1] are doing a bang-up job. However, they keep saying that what we need is to not send stuff to them until it's *really* ready, vis, RTBC should be rock solid and not require effort on their part anymore. There is no one besides them, really, who is in a position to say when something really is "ready to be committed". That's where most projects bring in subsystem maintainers. As database system maintainer for D7, I read and respond to almost every issue that comes through the DB component queue. I've also spent time with Angie trying to work out a good way to optimize the workflow from me to her, so that patches that get past me bubble up to her quickly, she knows they're ready, she knows where we need feedback before we can continue, etc. I think we've got a decent system, but I'm sure it could be improved. The result, though, is that the pace at which work is getting done in the DB layer is improving. We need that for the rest of core, too. Now, I'm not saying that to in any way malign the other people listed in MAINTAINERS.txt. I am saying that there are far too people in MAINTAINERS.txt. Right now, there's 12 entries in MAINTAINERS.txt[2], and some are the same people repeated multiple times. There are 60 separate "components" listed for Drupal, most of them specific modules or subsystems. That leaves (oh I hate arithmetic) 48 sub-pieces of core that fall under the "The rest: Dries Buytaert", that is, left to random passers by to not just review but also keep consistent and uncrufty. Not all of those components needs a dedicated person just for that piece, of course, but right now there's simply far too many people taking "ownership" over parts of core, in any version. Hell, I can't even find someone to take ownership of the Postgres driver. :-) As an extreme example, Linus Torvalds almost never reviews individual patches anymore. The subsystem maintainers maintain their pieces, and then send rollups to Linus that he reviews en masse and/or accepts that the subsystem maintainer knows what he's doing and just commits it. Of course, Linux has an order (or two) of magnitude more code than Drupal and they're also using a distributed VCS that is designed for that workflow (and no, I am NOT trying to bring that debate up again so don't even start), but it is a datapoint we should consider. So the question then becomes how do we get more people willing to long-term adopt parts of core and actively maintain it, to the point that the core committers work mostly with the subsystem maintainers who in turn work with the issue queue for their part of core? How do we streamline that process, *and* attract the people who can handle that job? I don't have an answer for those questions yet (if I did, we'd have a Postgres maintainer by now), but I do believe those are the important questions to be asking. [1] http://drupal.org/project/issues?projects=3060&states=2 [2] http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=markup -- Larry Garfield larry@garfieldtech.com