RE: Module-specific patch procedures?

[Murray Cumming Comneon com]

Yes, I think product-specific bug-triaging tips would be very helpful,
though I don't think it has much to do with where patches go. If someone
starts this page then hopefully maintainers will gradually add to it.

> > 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/msg00
005.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