[gentoo-dev] Re: Bugzilla - New Default Status Workflow
On Fri, 11 Mar 2011 04:52:19 +0100 Jeroen Roovers j...@gentoo.org wrote: On Thu, 10 Mar 2011 21:06:54 +0100 Amadeusz Żołnowski aide...@gentoo.org wrote: Status = NEW Assignee = bug-wranglers - Status = UNCONFIRMED Status = NEW Assignee = [maintainer] - Status = CONFIRMED Who confirms the bug? I would expect that CONFIRMED is set by the package maintainer and the one who assigns bugs leaves the status. I was referring to existing bug reports, not new ones. New ones should come in as UNCONFIRMED and would be changed to CONFIRMED when assigned - bug wrangling does have this element of validation, you know. Apparently when maintainers accept the bug, it changes to IN PROGRESS, and when [s]he doesn't it should be resolved as invalid or duplicate or whatever, but heck, maybe the flow chart should speak for itself. Bug wranglers should only mark bugs CONFIRMED if they can personally reproduce them. If no one has produced the bug other than the original poster then that's the very definition of UNCONFIRMED. Or maybe you're thinking CONFIRMED as in I confirm this is a bug report and not a lunch order? -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: Bugzilla - New Default Status Workflow
Michał Górny posted on Mon, 07 Mar 2011 09:34:55 +0100 as excerpted: I'd say, both to UNCONFIRMED. Before, we used to set 'NEW' for newly- added bugs and didn't use UNCONFIRMED often. Right now, it seems logical to use UNCONFIRMED for the new bugs and let devs (re-)confirm them as necessary. I've wondered about that choice in the past, but tended to simply leave it at the default (new), figuring (while having my doubts about viability) if they were both available and new was the default, unconfirmed must be an intentional downgrade available for users who weren't sure yet, and were going to follow up later after further tests. I think it might be even a good idea to limit the possibility of setting 'CONFIRMED' to devs. Otherwise, I see users bumping each of their bugs to 'CONFIRMED' immediately. Is it possible to leave that option for users, but block it such that the original filer can't flip it? If so, IMO that would be best, as a second user could then confirm it. If it's not possible to block, unconfirmed could at least be made the default and the wranglers could complain about (and change) bugs filed as confirmed as they assign them. The message should eventually get out, and having a second user confirm the bug could actually be quite useful for busy devs trying to prioritize their bugs. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: Bugzilla - New Default Status Workflow
On Sun, 6 Mar 2011 14:17:37 +0100 Christian Faulhammer fa...@gentoo.org wrote: Hi, Christian Ruppert id...@gentoo.org: We're almost done with the preparation of bugzilla-4.x for bugs.gentoo.org. So, do we want the new workflow or do we want to keep the old? New one, reopened is a bit pointless information on first glance. History tells enough. It's an important flag for a bug wrangler. jer
[gentoo-dev] Re: Bugzilla - New Default Status Workflow
Hi, Christian Ruppert id...@gentoo.org: We're almost done with the preparation of bugzilla-4.x for bugs.gentoo.org. So, do we want the new workflow or do we want to keep the old? New one, reopened is a bit pointless information on first glance. History tells enough. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
