GNOME Bugzilla – Bug 315146
Improve patch search
Last modified: 2018-06-16 13:27:27 UTC
So I don't forgot it.. desrt or just have a listview with all of the patch categories in it so you can do the multiple-selection thing bkor yeah good idea.. I'll see if it is easy to do (elijah wrote most of the search part, I made the frontend / searchpage) desrt what would be absolutely ideal if it was rolled into the main search interface bkor desrt, true, but then you'd get a normal buglist.. I'll try to improve it for bugzilla 2.20 desrt :)
I had thought some of the same things earlier. In fact, it could be nice to have a checkbox in query.cgi which, if checked, would forward the query to patchlist.cgi (a fork of buglist.cgi with a format akin to patch-report.cgi) and otherwise would send the query to buglist.cgi. If this is done, we could probably just get rid of patch-report.cgi. As far as short-term solutions go, though, it would be nice to have patch-report.cgi allow multiple patch-status types at once and default to showing unreviewed & accepted-commit_now & accepted-commit_after_freeze ones (and to keep the patches separate, i.e. it's split by product & component right now but it'd be nice to have patch-type be a third level of categorization on that page.
I'd suggest that improving buglist.cgi and query.cgi are throwing energy and time into the wrong problem. If we want to make things easier to use, give developers and users a one-stop shop for their project, with all the relevant, important queries right there, summarized and linked to- something like: http://jira.codehaus.org/browse/MAVEN not like query.cgi. Just add patch information to something like that, instead of making people fumble for Yet Another Checkbox in that god-awful monstrosity.
I agree that we need a cleaner overview page, but I don't see how that makes work on query.cgi, buglist.cgi, and patchlist.cgi a waste of effort. I think the page you suggest is important and should be available to developers before they ever go to query.cgi, BUT I think the way such a page would be implemented is to use buglist.cgi and patchlist.cgi (where 99% of the work would go for what I was suggesting). Further, I think that even with a page like you suggest we need query.cgi as a backup or the cool summary page itself will be forced to become unwieldy and lose its usefulness (I think there's a good parallel here to Gnome with preferences and the existence of gconf-editor--many more preferences exist and should be accessible somehow but should be kept out of the main UI...)
Btw.. http://bugzilla-test.gnome.org/browse.cgi is an old very simple unfinished needs-attention incomplete (enough hints?) version of the browse interface.
Should we make the browse.cgi page a third tab of query.cgi? I.e. have a query.cgi?format=specific, a query.cgi?format=advanced, and a query.cgi?format=product-overview. (Or should we just make it a prominent link elsewhere?) And whatever we name it (browse.cgi or query.cgi?format=product-overview), we should add some basic patch stats (not just how many, but a link for relatively new ones), any bugs that appear on showstopper lists, i18n/l10n buglists perhaps (especially just before string freeze), and maybe a couple other things... :)
Not sure where to put it.. query.cgi in 2.20 automatically remembers what query format you used last. This might be handy for some people. However, that would require hacking browse.cgi into query.pl. Should be too hard; detect the query format and put everything in a browse.pl (or whatever). Even if it was in another file, using the same templates + making it appear to be a part of query.cgi shouldn't be too hard.
Okay, perhaps I'm going off-topic, but I don't see a different bug to put this in. Anyway, extra ideas (besides various patch statistics and patch links, showstoppers, and i18n/l10n bugs listed above) for the browse.cgi interface (not necessarily 'good' ideas, just ideas): - A boogle search box, which implicitly prepends product:foo to the search (you know, kinda like http://www.google.com/linux). - Common queries such as those found at http://bugzilla.gnome.org/reports/reports.cgi#maintainers - A link to describecomponents.cgi?product=foo - The stuff from the maintainer section on the current front page of bugzilla.gnome.org - A link to http://live.gnome.org/MaintainersCorner
*** Bug 702373 has been marked as a duplicate of this bug. ***
After https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure , GNOME is moving its task tracking from Bugzilla to GitLab at https://gitlab.gnome.org/ as previously announced in https://mail.gnome.org/archives/desktop-devel-list/2018-May/msg00026.html . See https://wiki.gnome.org/GitLab for more information. Hence closing this ticket as WONTFIX: There are no plans to work on Bugzilla.