On Fri, 5 Feb 2016 16:10:48 -0500 Michael Orlitzky wrote: > On 02/05/2016 03:47 PM, Rich Freeman wrote: > > The main problem I see with auto-assignment is that some asignees end > > up being black holes for bugs. If two active devs get their bugs > > crossed it isn't a big deal since they'll just reassign them to each > > other. If an active dev gets their bug assigned to an inactive dev, > > they might never hear about it. > > > > We already trust users to tell us what went wrong and put bugs in the > right component. I think we can trust the package atom if one exists in > the summary. How about, if there's (exactly) one portage-compatible atom > in the summary and that package has (exactly) one maintainer, we > auto-assign it? Otherwise, leave it to the bug wranglers.
Automation can go further: if there are multiple maintainers, assign bug to the first one and CC others. As long as a package have a valid CP, maintainers will see them via a simple bugzilla query. Afaik this is a good idea to loop through all open package bugs before stabilization or version bump. Most (all?) bug wranglers are devs, so their time can be spent for better use, e.g. fixing actual bugs. Anyway bug wranglers will still have job: many bug reports doesn't contain a valid CP. The only concern I have with this: sometimes bug title reference multiple packages and it is possible that it will contain one valid CP and another one will be incomplete/invalid, e.g. "mplayer fails to build with dev-libs/openssl". In this case bug may be improperly auto assigned. But such cases should be quite rare thus tolerable. Another note: atom validity check should be performed for CP, not CPV, since many bugs affect all versions of a package in the tree, I often file such bugs myself :) Best regards, Andrew Savchenko
pgp5ykgJ4ZqWv.pgp
Description: PGP signature
