- The UNCONFIRMED bug status (which can be disabled per product) will be removed as it is mostly not used and confuses reporters. Tickets with UNCONFIRMED status will be merged into NEW status as announced on desktop-devel-list and at the top of every GNOME Bugzilla page.
If you are a GNOME project maintainer and want to keep the UNCONFIRMED status for your GNOME Bugzilla product you can opt out until the end of February. - I encourage you to give the product pages and your user page a try!
They have become more useful:
Browse Product
- Target Milestones (if existing), Priorities (if actually used and not just kept as the “normal” default) and Severities are now listed first, to get a quick overview for those projects who might use Bugzilla to do some project planning (so far I have not seen that much though). Static information like components or versions now comes after.
- Versions now sorts by newest versions first. You should be more interested in bugs reported in recent versions.
- The previously shown needless NEEDINFO queries by date were moved to the side bar and merged into one query. The query results are sorted by last change.
- In the side bar, “Bugs without a response” is a link again (though it is not exactly what it says, it’s rather a query for reports with only a single comment, hence also a mismatch between the displayed number and the search result number when you click it)
- Moved “New Patches” into its own new “Patches” section under “New and unreviewed”. All patch related information for a project is now in a single place. Click it and review a patch!
- The “GNOME-love bugs” query shows reports that have been recently changed first – more likely that recently changed ones are not outdated and something new contributors could work on.
- The “activity” link next to “Git repository” could give contributors a quick idea how maintained the project is (only works if the project is hosted in GNOME Git).
Describe User
- Your patches are now listed right after “What bugs are assigned to me” and “On which bugs do I need to provide input” and above the long list of “Open issues” that you once upon a time filed. Patches now also display the summary of the corresponding bug report. (Still have to remove the useless patch ID.)
- With above changes I’d like to make the “Browse Product” and “Describe User” pages give answers to “What is important?” and “What should I work on / review?”. I’d appreciate feedback if that’s considered helpful. For bugzilla.gnome.org itself this works pretty well, as you can see on its product page.
- Not yet available: I want the frontpage to look like this (thanks to jimmac for the custom icons; ignore the wrong color of the top bar):
Potential future frontpage
This was already live for a few minutes but I reverted this change as the server started cycling through cached older versions (no idea what happened), plus I have the feeling that the skin handling is still problematic (my fearless guinea pig Shaun still had Bugzilla’s “Dust” skin enabled in his user settings so things looked pretty broken). Need to make sure that everybody uses the GNOME skin before doing further custom skin changes. - 18 months ago I blogged a series of Bugzilla related posts. Though this focused on Wikimedia Bugzilla, there might be some helpful information or tweaks you are not aware of:
- Saved and shared searches
- Changing the columns in search results
- Creating reports and tables
- Autocompletion in UI fields
- Getting copies of another user’s bugmail
- Searching for empty fields
- Simpler searching for open tickets only
- Excluding less important reports from search results
- Reports: Tickets closed last week by resolution
I’ve forced everyone to use GNOME as their skin. Anything else we don’t test anyway.
I don’t like the change for the NEEDINFO bugs. The NEEDINFO links were useful to close them and mark them as RESOLVED INCOMPLETE, only for those that weren’t changed for e.g. 3 months or 6 months. Now it’s less convenient and there is no incentive to close them since they are all in one group.
Also, why not automatically close NEEDINFO bugs after some time without any response?
@Olav: Awesome, thanks! That explains zeenix’ comment on IRC today. :)
@Sébastien Wilmet:
Save your custom query (which will be shown in the footer) only showing NEEDINFO older than three months and the problem is solved. And as the list of NEEDINFO tickets shows the “last changed” column it should not be too hard to scroll a little bit down, is it?
Regarding automatic closing of NEEDINFO tickets, feel free to discuss more broadly and if there is consensus, write the code. Note though that many folks forget to reset the status. That’s the problem to solve first, like a “Did you provide the requested information in your comment and should the NEEDINFO status be removed?” dialog or such. Again, that requires code that someone needs to write.
I thought it was a good practice to close NEEDINFO bugs after some time. With only one link for all of them, it isn’t convenient and, more importantly, it _removes_ (partly) the incentive to close them. When the NEEDINFO bugs were clearly separated into different links, from time to time a maintainer could think (in a day with a good mood) “oh I’ll close all those old needinfo bugs that are in the > 6 months categories”, perhaps with the ‘Change Several Bugs at Once’ link.
Now, since all the NEEDINFO bugs are in only one link (by default), we cannot have a direct overview of the situation. We must take the initiative to actually click on the link, see the dates, etc. With this extra step, I think less people will close the NEEDINFO bugs. Which is not a big problem, of course. But doing some clean-up on bugzilla doesn’t hurt.
Also, if the NEEDINFO bugs are closed less frequently, the risk is to accumulate a too big amount of bugs to close that nobody wants to close them all. And creating a custom search query for that is not really convenient.
The potential for confusion around UNCONFIRMED vs. NEW was tackled upstream when they introduced the Bugzilla 4 bug life cycle changes. I get runing thr migration script is optional and that this will break bookmarks but hacking up the Bugzilla 3 model to fix something addressed in 4 seems like delaying the inevitable.
The new model is:
UNCONFIRMED -> COMFIRMED -> IN PROGRESS -> RESOLVED -> VERIFIED
https://www.bugzilla.org/docs/4.4/en/html/lifecycle.html
That is actually worse. Almost nobody takes any effort to mark bugs as new. With such a change, you’d call every bug confirmed while most products on GNOME bugzilla do _not_ make any distinction between those states! Most bugs really are in the maybe_confirmed_maybe_not state. Calling that NEW is ok.
ASSIGNED -> IN PROGRESS is nicer though.
The NEEDINFO problem would benefit from this feature: https://bugzilla.mozilla.org/show_bug.cgi?id=121335
Then we could query, which older NEEDINFO reports have the last comment from the original reporter.
@Sébastien Wilmet: As I wrote earlier: “the list of NEEDINFO tickets shows the ‘last changed’ column”. The small disadvantage might be that you only see the full number of NEEDINFO tickets, and in theory all of them could be from one day ago (so nothing to close yet). I consider that acceptable when it comes to limited screen estate and that planning is more important. Again, you are free to save custom queries and I’m happy to adjust the options if several people dislike the new behavior.
Generally, with the “Last column” being displayed in the list of NEEDINFO bugs, I consider it manageable to do the math (it’s February, let’s go through NEEDINFO bugs with no change since November 2014).
@Leif: I only consider UNCONFIRMED vs. NEW an issue if maintainers really *want* to differentiate. And most maintainers in GNOME seem to not see the need to do that.