Re: Killing off UNCONFIRMED in Bugzilla
On Fri, Feb 13, 2015 at 06:43:35PM +0100, Sébastien Wilmet wrote: For example in gedit UNCONFIRMED means that the bug is not triaged. With NEW, you're sure that the bug exists (or existed) and should be fixed upstream. What about NEW and CONFIRMED statuses? Those are more positive than UNCONFIRMED. So all NEW bugs would first be transformed as CONFIRMED, and then UNCONFIRMED - NEw (not in the reverse order of course). Or is it possible to search bugs that haven't been touched by any developer of that product? Because the idea with NEW/CONFIRMED is to be able to search bugs or feature requests that are approved by at least one maintainer of the product. If a bug hasn't been touched by a maintainer, it's probably an untriaged bug. Or do you have other solutions to filter out untriaged bugs when doing a search? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Sat, 2015-02-14 at 21:27 +0100, Sébastien Wilmet wrote: A bug triager only needs to look at UNCONFIRMED bugs. I strongly disagree with that statement. Triage takes place across the full life cycle of a report [1]. A contributor willing to fix a bug has more chances to find a real bug with the NEW status. A new contributor willing to fix a bug might be better off picking a gnome-love bug. There's a query for them on the product browse page, sorted by latest update so rotting bug reports are listed last. IMO, more chances to find a real bug only applies in a well-gardened bug repository where constant triage takes place so all tickets are in good and up-to-date shape. It's even more important for feature requests. If a contributor provides a patch for an unconfirmed feature request and then the bug is closed as wontfix, I think the contributor won't come back ;-) So triage incoming bug reports and set proper expectations by setting status RESOLVED WONTFIX for such tickets right away, instead of spending the approx. same amount of time for changing status UNCONF to NEW? The UNCONFIRMED status can be kept around to not break URLs, but would be hidden by default, no? Your bookmarked query for open tickets which searches for statuses UNCONFIRMED, NEW, ASSIGNED, REOPEN will not magically include those open tickets with a newly introduced new status (e.g. CONFIRMED)... Cheers, andre [1] See e.g. section Question Time on page 6 of http://thomas-zimmermann.com/publications/files/breu-cscw-2010.pdf -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Sat, 2015-02-14 at 19:02 +0100, Sébastien Wilmet wrote: On Fri, Feb 13, 2015 at 06:43:35PM +0100, Sébastien Wilmet wrote: For example in gedit UNCONFIRMED means that the bug is not triaged. How and to who does it actually matter? If it currently means that no developer will take a look at those tickets (though some of them might be totally valid) and if no other triagers are around, wouldn't it make sense to get rid of UNCONF so developers might suddenly accidentially look at such tickets? ;) What about NEW and CONFIRMED statuses? I am reluctant to rename statuses; see my other email. Or is it possible to search bugs that haven't been touched by any developer of that product? Currently not possible as far as I know: Bugzilla's Custom Search at the bottom of Advanced Search allows Commenter | is not equal to | %group.setproductnamehere_developers% but that criterion is already true when at least one commenter (e.g. reporter) is not member of the developers group for that product. Relatedly, https://bugzilla.gnome.org/page.cgi?id=browse.html now offers a Bugs without a response link again in the sidebar. But that is a lie as it only offers tickets with exactly one comment. Still better than nothing I thought, as long as upstream does not fix https://bugzilla.mozilla.org/show_bug.cgi?id=704842 ... Cheers, andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Sat, Feb 14, 2015 at 09:09:10PM +0100, Andre Klapper wrote: On Sat, 2015-02-14 at 19:02 +0100, Sébastien Wilmet wrote: On Fri, Feb 13, 2015 at 06:43:35PM +0100, Sébastien Wilmet wrote: For example in gedit UNCONFIRMED means that the bug is not triaged. How and to who does it actually matter? If it currently means that no developer will take a look at those tickets (though some of them might be totally valid) and if no other triagers are around, wouldn't it make sense to get rid of UNCONF so developers might suddenly accidentially look at such tickets? ;) A bug triager only needs to look at UNCONFIRMED bugs. A contributor willing to fix a bug has more chances to find a real bug with the NEW status. It's even more important for feature requests. If a contributor provides a patch for an unconfirmed feature request and then the bug is closed as wontfix, I think the contributor won't come back ;-) What about NEW and CONFIRMED statuses? I am reluctant to rename statuses; see my other email. The UNCONFIRMED status can be kept around to not break URLs, but would be hidden by default, no? Relatedly, https://bugzilla.gnome.org/page.cgi?id=browse.html now offers a Bugs without a response link again in the sidebar. Yep, it's really nice to have this link. But some untriaged bugs have some responses (by the same person or other people). The same for feature requests, some are not confirmed and some people add comments I want that too. Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla (renaming status names)
On Fri, 2015-02-13 at 21:43 +0100, Alexandre Franke wrote: BTW since 4.0 the new default workflow in bugzilla starts with UNCONFIRMED → CONFIRMED. This can be useful for those that keep UNCONFIRMED because sometimes reporters misinterpret NEW as not touched yet. Renaming the default status names in upstream made sense. For existing instances it breaks any bookmarks in your browser for search queries using URL parameters like bug_status=UNCONFIRMED. To me that is enough reason to be reluctant. andre PS: There is some undocumented alias feature in Bugzilla (no idea if it works with URL parameters) if anyone wants to play with that: http://bzr.mozilla.org/bugzilla/4.4/view/head:/template/en/default/global/value-descs.none.tmpl -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Sat, 2015-02-14 at 22:12 +0100, Andre Klapper wrote: On Sat, 2015-02-14 at 21:27 +0100, Sébastien Wilmet wrote: A bug triager only needs to look at UNCONFIRMED bugs. I strongly disagree with that statement. Triage takes place across the full life cycle of a report [1]. A contributor willing to fix a bug has more chances to find a real bug with the NEW status. A new contributor willing to fix a bug might be better off picking a gnome-love bug. There's a query for them on the product browse page, sorted by latest update so rotting bug reports are listed last. IMO, more chances to find a real bug only applies in a well-gardened bug repository where constant triage takes place so all tickets are in good and up-to-date shape. Just wanted to point out that most projects which use gnome bugzilla are relatively small and have bug counts in the mere hundreds, with the exception of a few central products like GTK+. To be frank, with bug counts numbering 3 or 4 hundred, I have only ever had use for UNCONFIRMED and RESOLVED. However I could see that with a product like mozilla or libreoffice, it totally makes sense to have triaging and confirmed status and the like. That said, I honestly dont care if NEW becomes the new UNCONFIRMED so long as little to no damage is caused by this. It certainly wont magickly cause maintainers of said modules to have more time to deal with bugs - if some people feel that UNCONFIRMED is a rude way to express the NOT RESOLVED status, and would prefer to call it NEW, then that, in itself doesnt bother me at all :) Best, -Tristan It's even more important for feature requests. If a contributor provides a patch for an unconfirmed feature request and then the bug is closed as wontfix, I think the contributor won't come back ;-) So triage incoming bug reports and set proper expectations by setting status RESOLVED WONTFIX for such tickets right away, instead of spending the approx. same amount of time for changing status UNCONF to NEW? The UNCONFIRMED status can be kept around to not break URLs, but would be hidden by default, no? Your bookmarked query for open tickets which searches for statuses UNCONFIRMED, NEW, ASSIGNED, REOPEN will not magically include those open tickets with a newly introduced new status (e.g. CONFIRMED)... Cheers, andre [1] See e.g. section Question Time on page 6 of http://thomas-zimmermann.com/publications/files/breu-cscw-2010.pdf ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
