Getting xserver patches reviewed

[Donnie Berkholz]

On 01:18 Sun 25 Nov     , Barton C Massey wrote:
> There's clear demand for some more formal and viable process
> for getting patches reviewed and accepted.  It's great that
> Daniel and a few others try to keep up with this stuff, but
> they're pretty clearly overwhelmed; one can only do so much
> of this kind of support while also contributing new work.

I agree that it's clear that patches slipped, and there's clear demand 
to fix this. Is formality the answer?

> What we really need is someone with good organizational
> skills to put together and be responsible for the right
> process.  The kernel does give us something of a model to
> start with.  I'd suggest that some lead person needs to

Are you basically suggesting something like GNOME's Bugmaster [1]?

>   * Identify subsystems that need maintenance.  These
>     probably correspond to modules or groups of modules in
>     the build.

Need maintenance ... I suppose I'd define this as "has open bugs or 
pending patches"?

>   * Identify or recruit maintainers for these subsystems.
>     Maintainers should have the power to grant commit
>     privileges to their "master" tree at freedesktop.org,
>     and to manage commits for their subsystem.  The
>     modularization should make this easy...

The identification should already be handled by the MAINTAINERS file in 
xorg-docs. The rest of this is pretty much already in place, with 
approval for new committers and git-revert. What do you do about modules 
nobody wants to maintain?

>   * 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.

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.

Thanks,
Donnie

1. http://tieguy.org/talks/LCA-2005-paper-html/