Re: Module-specific patch procedures?

[Elijah P Newren <newren math utah edu>]

On Tue, 2004-01-27 at 05:39, Murray Cumming Comneon com wrote:
> The Nautilus maintainers like to get patches emailed to their mailing list.
> They hate getting patches only in bugzilla. Most other maintainers hate
> getting patches on their mailing lists, and love getting patches in
> bugzilla. That's a statement and not a judgement. It's their module and they
> do a wonderful job.
> 
> Would it be possible for bugzilla to sometimes say "The maintainers of this
> module prefer to receive source code patches on the <emailaddress> mailing
> list."?
> 
> Some people have suggested a big page describing the various ways that
> various maintainers like to work. Personally, I don't think that there is
> that much variety.

I was probably one of the ones that suggested such a "big page".  Note
that in the case you're describing, I believe the method you suggest
would be better since patches can be important and it'd be good to have
an automatic, ensured response.  Thus if what you suggest is possible,
it should probably be preferred over what I had in mind.  However, I
still think what I had in mind is useful for other things.  Let me
explain more of what I was thinking of:

I thought it'd be useful to have a "big page" known as "Product-specific
Triaging Guidelines" (or something fairly similar).  The idea really
wasn't to describe the differences between how maintainers work (though
that could also appear on the page), but more a list of the special
things that can be done for individual products.  For example, many
gnome-terminal bugs are misfiled and should be filed against vte (e.g.
any gnome-terminal bug containing a stack trace with a function name
that has "vte" in it)  In fact, there are a number of other common
problems with gnome-terminal bug reports--so many that Havoc created bug
110623 so he could just mark other bugs as duplicates of it.  As another
example, Lars Clausen noticed I had covered a lot of dia bugs and sent
me an email to thank me and send me other pointers that would make it
easier for me to know what to do with a larger range of dia bugs (which
I later emailed to this list, see
http://mail.gnome.org/archives/gnome-bugsquad/2003-April/msg00005.html).  Also, while triaging I noticed things like bug 81928 where I found out that gtcd was deprecated so I could start marking gtcd bug reports as duplicates of that bug.  A similar thing for bug 105471 & balsa.  The nautilus maintainers can't possibly cover all the bugs, so they just tend to want us to mark bugs against older versions as NEEDINFO automatically.  Metacity probably has a range of feature requests that they repeatedly get (some of which have been implemented, others of which won't be) and it'd be nice to have a quick place for triagers to quickly check.  Most gnome-desktop bugs reports should have actually been filed against nautilus (people don't know what nautilus is, but they know they were working "on their desktop").

I think a "product specfic guidelines" page would make it so that
triagers could handle a lot more bugs a lot more quickly, help those new
to the bugsquad who have a hard time knowing "where to start" find a
class of bugs to work on, reduce the burden on the maintainers, and help
increase the communication between the bugsquad and the maintainers. 
Anyway, that's what I had in mind.  I'm too busy (lazy?) to work on it
myself right now, though.  However, would people be opposed if someone
else on the bugsquad decided to pick up this project?  I think it'd be a
great project even for someone relatively new (we could even announce it
on gnome-love).  However, before someone goes off to announce it (or
should I s/before/if/?), it'd be nice to find out if everyone else
agreed or if they thought I was off my rocker (not that those have to be
mutually exclusive...).  Comments? 

Elijah