[development] How to post bug reports and patches

Sat Nov 1 09:37:55 UTC 2008

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 at garfieldtech.com