Getting xserver patches reviewed

[Barton C Massey]

In message <20071125100618.GK4368 at supernova> you wrote:
> 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?

I dunno.  It might at least be a way to get a handle on the
problem.

> > 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]?

Probably.  Or something like one or more of Linux's lead
developers.  Or something.  Anything we can get someone to
do, I guess.

> >   * 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"?

Better IMHO: is a non-deprecated, commonly-used piece of the
currently-shipped codebase.

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

This appears not to be sufficient for outside contributors.
They don't really figure out who the maintainer is, and when
they do figure it out half the time it's useless for various
reasons.  And do they contact the maintainer or the email
list or the bug database or some multiple of the above? If I
didn't happen to have a direct line to key people, I don't
think I would have much success in getting stuff looked at
either.

> What do you do about modules nobody wants to maintain?

There's lots of possibilities.  For example, if the module
isn't absolutely mission-critical, one approach would be to
just mark it dead so that people will know; quit taking bug
reports and patches and put a big note in a prominent place.
If someone wants it bad enough, they can claim it...

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

Yeah, I'm good with Bugzilla if people want to really make
it do tricks. What tends to happen even with well-maintained
pieces in my experience is that a giant backlog of entries
builds up that is completely un-responded-to; this seems to
me to be a bad thing on many levels.  The graphing would be
good to start turning on, at least.

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

I just think it's important to (a) know the extent of the
problem we're having, which IMHO we really don't right now,
(b) give good feedback to outside contributors and bug
reporters about what happened with their stuff and why (even
if the answer is "it got dropped on the ground because no
one had time for it" it would be good to give this answer in
a timely fashion, along with some advice about what to do if
they want to persist), and perhaps (c) start to make a more
focused effort to recruit outside developers to take
administrative responsibility for narrow slots in which they
have technical expertise and are needed---which of course
means knowing what these slots should be.  I'm not an
advocate of process for process' sake, but it seems to me
that right now the mess might actually be hurting us as much
as any actual lack of responsiveness or community spirit.

At the least it seems to me that someone (and I am
volunteering to help with this) needs to document very
clearly for outside people how to use the current
combination of email list(s), Bugzilla, wiki, git,
maintainers file, etc to achieve a maximum chance of having
their contribution and/or bug report actually be
integrated---which first means that "we" need to achieve or
identify some consensus on what these instructions should
be.

    Bart