[development] How to post bug reports and patches
larry at garfieldtech.com
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 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
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, 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
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
larry at garfieldtech.com
More information about the development