Re: Killing off UNCONFIRMED in Bugzilla (renaming status names)
On 23/02/15 19:58, Andre Klapper wrote: On Mon, 2015-02-23 at 19:03 +0100, Andres G. Aragoneses wrote: If the alias feature ends up working, I'd like to add my 2cents here: For projects that opt-out, IMO the statuses should be UNCONFIRMED-CONFIRMED, as other developer has already suggested. I do not want both CONFIRMED and NEW statuses in Bugzilla, especially as you cannot disable one or the other per product. Too much confusion. Ok but my suggestion about OPEN remains. UNCONFIRMED-OPEN doesn't look too confusing. ___ 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 13/02/15 22:30, Olav Vitters wrote: On Fri, Feb 13, 2015 at 04:51:58PM +0100, Olav Vitters wrote: Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! I'm keeping track of opt-outs at https://wiki.gnome.org/BugzillaMaintainers/NoUnconfirmed Feel free to edit, though would appreciate a comment why you opt out. FYI just added banshee. ___ 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 14/02/15 20:50, Andre Klapper wrote: 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 If the alias feature ends up working, I'd like to add my 2cents here: For projects that opt-out, IMO the statuses should be UNCONFIRMED-CONFIRMED, as other developer has already suggested. For the rest, the status NEW should really be renamed to OPEN. NEW has always had a horrible name, why NEW and not OLD? It's kinda confusing (for newcomers) too that oldest open bugs are still in NEW state. Thanks ___ 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 Mon, Feb 23, 2015 at 1:22 PM, Andres G. Aragoneses kno...@gmail.com wrote: Ok but my suggestion about OPEN remains. UNCONFIRMED-OPEN doesn't look too confusing. UNCONFIRMED/NEW - UNRESOLVED would be my suggestion. ___ 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 23/02/15 21:38, Michael Catanzaro wrote: On Mon, Feb 23, 2015 at 1:22 PM, Andres G. Aragoneses kno...@gmail.com wrote: Ok but my suggestion about OPEN remains. UNCONFIRMED-OPEN doesn't look too confusing. UNCONFIRMED/NEW - UNRESOLVED would be my suggestion. That suggestion is not clear. Andre has said that the NEW status cannot be different in the case of projects opting out of the UNCONFIRMED removal. So then there can only be 2 status names, not 3 as you suggest. ___ 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 Sun, Feb 15, 2015 at 11:07:50AM +0100, Sébastien Wilmet wrote: On Sat, Feb 14, 2015 at 10:12:22PM +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]. I meant, look at UNCONFIRMED bugs _in priority_, since those were probably not triaged at all. Also, there is a difference between the daily triaging, i.e. answering in bugzilla after receiving a mail notification; and triaging old bugs by looking directly in bugzilla. For the latter, I look first at UNCONFIRMED bugs. And for the former, do we really call that triaging? ___ 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 10:12:22PM +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]. I meant, look at UNCONFIRMED bugs _in priority_, since those were probably not triaged at all. 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. And for all other contributors like me? gnome-love is fine for the first one or two patches. Beyond these, searching the bugs marked as NEW is a good way to find real bugs that need to be fixed upstream. 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? Ok, but what to do with all the old bugs that are not well triaged? gedit contains more than 400 bugs, and triaging all of them takes a lot of time. If one day all of them are well triaged, then yes, it makes sense to remove the UNCONFIRMED status (but in that case we must be sure to well triage all new incoming bugs, and history has shown that it's not always the case). 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)... Yeah, right. 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
On Sun, Feb 15, 2015 at 11:07:50AM +0100, Sébastien Wilmet wrote: On Sat, Feb 14, 2015 at 10:12:22PM +0100, Andre Klapper wrote: 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? Ok, but what to do with all the old bugs that are not well triaged? gedit contains more than 400 bugs, and triaging all of them takes a lot of time. If one day all of them are well triaged, then yes, it makes sense to remove the UNCONFIRMED status (but in that case we must be sure to well triage all new incoming bugs, and history has shown that it's not always the case). 400 bugs is not a huge number to triage. It seems you're talking about multiple things. For triaging bugs, you have to deal with loads of bugs which are in UNCO status, but have been triaged. Meaning: they are real bug but never moved out of UNCO. When looking for bugs to fix, you'll have to look at UNCO as well as NEW. But looking for bugs to fix is not triaging. While triaging it is easier to say that you looked at it vs knowing it really is a bug. Together with the amount of emails being sent I usually leave things as UNCO. Ideally you'd first have everything handled by a triage team, then it goes to a developer. If there's a new developer you'd want to give them a list of bugs. I don't see how UNCO vs NEW in the current usage is beneficial. Practically for most products no distinction is made _at all_. Bugs are randomly spread across both statuses. -- Regards, Olav ___ 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 Fri, Feb 13, 2015 at 04:51:58PM +0100, Olav Vitters wrote: Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! Please keep the UNCONFIRMED status for: gedit gtksourceview latexila ___ 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 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
Killing off UNCONFIRMED in Bugzilla
With Bugzilla 4.4 we can disable UNCONFIRMED on a per-product basis. With that option available, I suggest to kill off the UNCONFIRMED status for all products except whomever wants it. I think we had this discussion before, but couldn't easily find that. Reasoning to kill unconfirmed: Unconfirmed at various times gives the impression the bug will not be looked at. Not having this state would solve that. Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! Steps (for all products except the ones opting out): - Change use unconfirmed to false (product specific setting) - Mass change all unconfirmed bugs to new for all Timeline: I want to do this Friday 27 February 2015. -- Regards, Olav ___ 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
Hi, On Fri, Feb 13, 2015 at 4:51 PM, Olav Vitters o...@vitters.nl wrote: Reasoning to kill unconfirmed: Unconfirmed at various times gives the impression the bug will not be looked at. Not having this state would solve that. Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! Please keep it for gnome-music at least - we use this status to properly track issues, which might be caused by other projects. We UNCONFIRMED as 'untriaged' and/or 'potentially unclear'. Thanks, Vadim ___ 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 Fri, Feb 13, 2015 at 9:51 AM, Olav Vitters o...@vitters.nl wrote: With Bugzilla 4.4 we can disable UNCONFIRMED on a per-product basis. With that option available, I suggest to kill off the UNCONFIRMED status for all products except whomever wants it. This would be highly desirable. Bonus points if you do it without sending emails for each bug. ___ 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 Fri, Feb 13, 2015 at 06:39:29PM +0100, Rick Opper wrote: OK... So they just stay new then... I'm not sure that would give the original reporter the impression that something is being done, but as long as the bugs do get confirmed, sorted, whatever then any simplification may be helpful... Things will be done no matter which status it is for the majority of the products. Some products are not maintained at all anymore, for those the status still won't make much difference. The separate step might make sense in case you had a big bugsquad team looking at all the incoming bugs. We don't. The unconfirmed vs new status has little or no meaning. Loads of bugs actually go from unconfirmed to new. I tend to only mark it as new if there's a bunch of people on it and because some people don't understand that if I disagree with the bug, I would've already marked it WONTFIX. If people want to look at bugs they want to triage, there's already bugs filed in the last 7 days. Further, bugs without a response. In the current state, unconfirmed is not going to help you much. -- Regards, Olav ___ 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 Fri, 2015-02-13 at 18:39 +0100, Rick Opper wrote: OK... So they just stay new then... I'm not sure that would give the original reporter the impression that something is being done, but as long as the bugs do get confirmed, sorted, whatever then any simplification may be helpful... OTOH, some reporters or users get frustrated when products keep the UNCONFIRMED status, in spite that those bugs have plenty of comments, even from the product developers. I personally confirm bugs, but it does not mean I am going through hundreds of all bugs with undecided status, which does not mean I do not know what it is going on there. -- Germán Poo-Caamaño http://calcifer.org/ ___ 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 Fri, 2015-02-13 at 18:15 +0100, Rick Opper wrote: Then how will project devs know if a bug is - as the status implies - not yet confirmed? It may be a problem with a single users unique setup, Which is still a bug, and it's still new. or a design decision RESOLVED WONTFIX , or caused by something specific to a certain distribution... RESOLVED NOTGNOME Isn't that the point of this tag? There are other statuses available which already cover those cases. ___ 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 Fri, Feb 13, 2015 at 06:20:15PM +0100, Bastien Nocera wrote: On Fri, 2015-02-13 at 18:15 +0100, Rick Opper wrote: Then how will project devs know if a bug is - as the status implies - not yet confirmed? It may be a problem with a single users unique setup, Which is still a bug, and it's still new. or a design decision RESOLVED WONTFIX , or caused by something specific to a certain distribution... RESOLVED NOTGNOME Isn't that the point of this tag? There are other statuses available which already cover those cases. It's useful to distinguish UNCONFIRMED and NEW. Some products in gnome have many hundreds bugs, and triaging all of them takes a lot of time. What you suggest needs to triage _all_ the bugs. 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. For someone willing to contribute, searching in more than 400 bugs is not really convenient. So by filtering the search results to include only the confirmed/NEW bugs, it's already much better (it's what is advised for newcomers on the gedit wiki). 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
Then how will project devs know if a bug is - as the status implies - not yet confirmed? It may be a problem with a single users unique setup, or a design decision, or caused by something specific to a certain distribution... Isn't that the point of this tag? On February 13, 2015 4:51:58 PM CET, Olav Vitters o...@vitters.nl wrote: With Bugzilla 4.4 we can disable UNCONFIRMED on a per-product basis. With that option available, I suggest to kill off the UNCONFIRMED status for all products except whomever wants it. I think we had this discussion before, but couldn't easily find that. Reasoning to kill unconfirmed: Unconfirmed at various times gives the impression the bug will not be looked at. Not having this state would solve that. Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! Steps (for all products except the ones opting out): - Change use unconfirmed to false (product specific setting) - Mass change all unconfirmed bugs to new for all Timeline: I want to do this Friday 27 February 2015. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ 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
OK... So they just stay new then... I'm not sure that would give the original reporter the impression that something is being done, but as long as the bugs do get confirmed, sorted, whatever then any simplification may be helpful... On February 13, 2015 6:20:15 PM CET, Bastien Nocera had...@hadess.net wrote: On Fri, 2015-02-13 at 18:15 +0100, Rick Opper wrote: Then how will project devs know if a bug is - as the status implies - not yet confirmed? It may be a problem with a single users unique setup, Which is still a bug, and it's still new. or a design decision RESOLVED WONTFIX , or caused by something specific to a certain distribution... RESOLVED NOTGNOME Isn't that the point of this tag? There are other statuses available which already cover those cases. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ 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 Fri, 2015-02-13 at 18:15 +0100, Rick Opper wrote: Then how will project devs know if a bug is - as the status implies - not yet confirmed? 1) Not all devs care about this. Those who care can keep the UNCONFIRMED status. That's what this thread is about, more or less. 2) Not everybody sees a need to query open bug reports based on status. For some, an I can reproduce this comment in the ticket might be sufficient, instead of expressing that via some ticket status. 3) If the person looking at tickets is a developer, s/he might reproduce the bug and fix it in the same step anyway. No need to spend time setting some status which might be workflow overhead. 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
Hi: I would like to keep it for both Contacts (gnome-contacts) and Calendar (gnome-calendar). I've been trying to follow this bug triage guidelines [1], and for me it means bugs I haven't even look at. Once I look at a bug, I move it into NEW, but it serves organizational purposes. [1]: https://wiki.gnome.org/AllanDay/BugManagement ___ 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 Fri, Feb 13, 2015 at 4:51 PM, Olav Vitters o...@vitters.nl wrote: Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! Please keep it for planner. 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. -- Alexandre Franke ___ 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 Fri, 2015-02-13 at 18:43 +0100, Sébastien Wilmet wrote: On Fri, Feb 13, 2015 at 06:20:15PM +0100, Bastien Nocera wrote: On Fri, 2015-02-13 at 18:15 +0100, Rick Opper wrote: Then how will project devs know if a bug is - as the status implies - not yet confirmed? It may be a problem with a single users unique setup, Which is still a bug, and it's still new. or a design decision RESOLVED WONTFIX , or caused by something specific to a certain distribution... RESOLVED NOTGNOME Isn't that the point of this tag? There are other statuses available which already cover those cases. It's useful to distinguish UNCONFIRMED and NEW. Some products in gnome have many hundreds bugs, and triaging all of them takes a lot of time. What you suggest needs to triage _all_ the bugs. 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. For someone willing to contribute, searching in more than 400 bugs is not really convenient. So by filtering the search results to include only the confirmed/NEW bugs, it's already much better (it's what is advised for newcomers on the gedit wiki). Then opt-out. I can tell you that UNCONFIRMED isn't used in, at least, gnome-shell, gnome-settings-daemon, gsettings-desktop-schemas, gnome-control-center, totem, totem-pl-parser, gnome-desktop, gom, grilo, or grilo-plugins. ___ 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 Fri, Feb 13, 2015 at 04:51:58PM +0100, Olav Vitters wrote: Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! I'm keeping track of opt-outs at https://wiki.gnome.org/BugzillaMaintainers/NoUnconfirmed Feel free to edit, though would appreciate a comment why you opt out. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
