Currently people tend to write randomly the summaries, for example, if mod_perl package is affected, some will write "mod_perl", others will properly write "www-apache/mod_perl..." summary, others won't even specify it... The idea would be the same as it's already implemented in many other bugzillas (like gnome or freedesktop ones) When people send a bug report they are forced to choose as a component (or write manually if you prefer) the ${CATEGORY}/${P} that is affected. That way we wouldn't need to manually fix the summaries, we neither would miss the bugs that weren't modified to fix that naming too Thanks
Additional proposal: it would be great to assign bugs (and CC if necessary) based on the metadata of the package selected in the box. This will reduce manual bug wrangling dramatically. Of course we should allow "upscpecified" option for cases where it is not clear which package is affected and "other" option for out-of-tree ebuilds, e.g. from overlays (alternatively overlays support may be added, but this may complicate things too much).
*** Bug 574774 has been marked as a duplicate of this bug. ***
Well, having components synced to packages is not an option. Components are pretty much static, and Bugzilla can't scale to such a huge number of components -- unless you find it a good idea for user to scroll over all packages... One option is to use a custom field for package(s). However, I'm not convinced it's actually beneficial. If you want to add a custom field to Bugzilla, you are presented with quite an explanatory warning: | Adding custom fields can make the interface of Bugzilla very complicated. Many | admins who are new to Bugzilla start off adding many custom fields, and then | their users complain that the interface is "too complex". Please think carefully | before adding any custom fields. It may be the case that Bugzilla already does | what you need, and you just haven't enabled the correct feature yet. So yes, we could add a field. But is there a real need to have one, when most of the people can specify the package in summary? Even if it's not 100% correct, I think a custom field won't make it more correct. That said, our package names are special enough to be caught by script. My bug assignment script [1] queries pgo for everything that looks like a package name -- and uses those which actually matched something. [1]:https://blogs.gentoo.org/mgorny/2016/06/17/bugs-gentoo-org-bug-assignment-userjs/
Thanks for the script, I will see how to use it :) Well, I agree that the components will not fit ok with our structure :S We would need then something to "warn" when a summary name doesn't follow the rule of starting by a pkg name (and maybe rely on some special Keyword for excluding special bugs). The idea would be to try to ensure they follow that standard pattern, they don't have typos or similar (Sometimes I have missed a bug simply because I was searching, for example, app-portage/eix and the summary had a bogus space in the middle like app-portage/ eix )
Oh, one more thing: if we added a custom field, we'd probably stop using packages in summaries. Then we'd have to modify most of the search views etc. to display the package besides summary. I don't know if we can do that for all developers, and some of us certainly have non-standard column sets displayed.
(In reply to Michał Górny from comment #5) > Oh, one more thing: if we added a custom field, we'd probably stop using > packages in summaries. Why should we do that? This make bug title readable and sometimes bugs affect more than a single package.
(In reply to Andrew Savchenko from comment #6) > (In reply to Michał Górny from comment #5) > > Oh, one more thing: if we added a custom field, we'd probably stop using > > packages in summaries. > > Why should we do that? This make bug title readable and sometimes bugs > affect more than a single package. Because most of the people will see typing the same thing twice redundant.
(In reply to Michał Górny from comment #7) > Because most of the people will see typing the same thing twice redundant. That box can be autofilled by bug title parsing, so manual changes will be needed rarely.
