Getting xserver patches reviewed

Bernardo Innocenti bernie at codewiz.org
Mon Nov 26 04:48:24 PST 2007


On 11/25/07 05:06, Donnie Berkholz wrote:

>>   * Put together a software system for queueing and triaging
>>     submitted requests to each subsystem.  This could be
>>     built on the current Bugzilla, but if so it needs to
>>     include mechanisms for notifying key folks when things
>>     aren't being addressed in a timely fashion, and for
>>     keeping statistics on outcomes.
> 
> Bugzilla should be able to handle this. It's got a QA contact field, and 
> it does graphing. I'd guess that nobody's using either of those 
> features, however, so that may be more of the change you suggest.

Please let's not use Bugzilla as a patch queuing system.
It's a recipe for 

 * Lack of public reviews

 * Small patches never being submitted due to laziness
   of filing a bug in bugzilla

 * Patches bitrotting for months in bugzilla before anyone
   notices

The LKML can effortlessly handle *thousands* of patches per
release.  Surely there is not yet a scalability problem for
Xorg.

Pinging patches is more than enough to make sure they don't
get lost.  My "strategy" is keeping all submitted patches in
a "xorg/sumbitted/" directory and moving them to "xorg/applied/"
or "xorg/rejected/" as appropriate.

This is really all the infrastucture that is required.
For people who prefer actual tools over self discipline,
git-rebase along with a "for-upstream" branch should be
more than adequate.


> Perhaps you could clear me up on this -- I'm not seeing how adding more 
> formality will help the lack of experienced developer time or the lack 
> of interest in some modules. To me, those seem like the source problems, 
> and the slipping patches symptoms.

Me neither... In fact, I'd go for an even less formal process :-)

The only thing that really matters is that there's only one (1)
maintainer in charge per area, willing to take the credit or
the blame for the patches he/she does (not) review.

This is not necessarily to say there shouldn't be anybody
else with commit privilege, or that nobody else should help
reviewing patches.

Why is this important?  For a simple sociological fact that
applies to many similar scenarios: if "everybody should remember
to water the plants in the office", then the plants will
certainly die and people will just point fingers at each other!

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



More information about the xorg mailing list