GNOME Bugzilla – Bug 740076
There is no way to set bugs as CONFIRMED
Last modified: 2015-01-03 20:04:49 UTC
At the moment the only options offered by the drop-down menu are: UNCONFIRMED NEW ASSIGNED NEEDINFO RESOLVED It would be great to be able to select CONFIRMED in the drop down list for bugs. Being able to confirm bugs would help figure out which bugs have not been looked at yet. At the moment in the absence of the CONFIRMED option, people seem to be using NEW to confirm bugs a lot so as a result there are a lot of old bugs labelled at NEW and a lot of bugs labelled as UNCONFIRMED.
In upstream, NEW was renamed to CONFIRMED in Bugzilla version 4.0. We're running 3.4. In most GNOME projects (except for GIMP and some others) there seems to be no disambiguation between UNCONFIRMED and NEW anyway and personally I doubt that the disambiguation is actually useful (if you cannot reproduce, set it to NEEDINFO though that's also not perfect if all steps and environment information have been provided the reporter so there's no question). If I could set this up from scratch again I'd rename NEEDINFO to STALLED. Furthermore, NEW is automatically set as the default status for reporters who have "editbugs/canconfirm" permissions and most people don't manually set the status to UNCONFIRMED. Yeah, it's all busted, it's Bugzilla. Personally I'm not sure what the difference between NEW and CONFIRMED would be.
(In reply to comment #1) > In upstream, NEW was renamed to CONFIRMED in Bugzilla version 4.0. We're > running 3.4. I'm a mind reader! :D I am curious... Is there a compelling reason why we aren't we using a more current version? > In most GNOME projects (except for GIMP and some others) there seems to be no > disambiguation between UNCONFIRMED and NEW anyway and personally I doubt that > the disambiguation is actually useful (if you cannot reproduce, set it to > NEEDINFO though that's also not perfect if all steps and environment > information have been provided the reporter so there's no question). > If I could set this up from scratch again I'd rename NEEDINFO to STALLED. > Furthermore, NEW is automatically set as the default status for reporters who > have "editbugs/canconfirm" permissions and most people don't manually set the > status to UNCONFIRMED. Yeah, it's all busted, it's Bugzilla. > Personally I'm not sure what the difference between NEW and CONFIRMED would be. NEEDINFO infers STALLED so essentially although they do not literally mean the information they provide invokes the same response for everyone scanning through the bugs to check their status' (arguably with the exception of the person the info is needed from, that is ;-)) NEW neither means CONFIRMED nor infers it either. CONFIRMED provides actionable information. CONFIRMED tells us "I better do something about that bug". NEW just says, "this is a bug that was recently filed" (and fwiw half the bugs tagged under NEW were not even recently filed either so it's not even good at doing its limited job, properly). I really think more people would be more motivated to adjust the status of a bug from UNCONFIRMED, if there was an appropriate option to change it to.
(In reply to comment #2) > I am curious... Is there a compelling reason why we aren't we using a more > current version? krnowak is currently working on upgrading. We've been stuck because nobody is really a maintainer and because there's (IMHO) too many customizations. We won't change any status names before running a recent version. Furthermore this will break any Bugzilla query URLs that people might have stored as bookmarks in browsers as status names are passed as URL parameters. To some extend, setting status aliases (after renaming) is possible in the codebase via http://bzr.mozilla.org/bugzilla/4.4/view/head:/template/en/default/global/value-descs.none.tmpl (but this is not covered by the Bugzilla docs). > NEW neither means CONFIRMED nor infers it either. CONFIRMED provides actionable > information. CONFIRMED tells us "I better do something about that bug". Boils down to the Q "Which criteria define a bug report status and which criteria are expressed by other means than a status?" I don't know either. I remember the idea of Mozilla's bugmaster to introduce a ''READY'' status. In my opinion that status resembles the practice of KDE and Mageia having ''triaged'' keywords, and Red Hat having ''Triaged'' and ''Unconfirmed'' keywords instead of potentially using a status for this (the ''Triaged'' keyword is added when a report has correct and enough data, according to https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow ).
(In reply to comment #3) > (In reply to comment #2) > > I am curious... Is there a compelling reason why we aren't we using a more > > current version? > > krnowak is currently working on upgrading. We've been stuck because nobody is > really a maintainer and because there's (IMHO) too many customizations. Can't say I disagree. So, the question is, which of them are vital to GNOME's infrastructure and which of them would be worth seeing the back of, I think. If the answer to that could be narrowed down to a few specifics then perhaps we might find that an upgrade wouldn't be so out of the question, after all? I have no idea what the vital customisations are though so I can't really say. > We won't change any status names before running a recent version. That's a bit depressing. > Furthermore this will break any Bugzilla query URLs that people might have > stored as bookmarks in browsers as status names are passed as URL parameters. > To some extend, setting status aliases (after renaming) is possible in the > codebase via > http://bzr.mozilla.org/bugzilla/4.4/view/head:/template/en/default/global/value-descs.none.tmpl > (but this is not covered by the Bugzilla docs). Serves them right for having incomprehensible bookmarks imho. Only joking. Well... I cannot fathom how anyone could find the NEW bookmark useful so I am not really joking. :D > > NEW neither means CONFIRMED nor infers it either. CONFIRMED provides actionable > > information. CONFIRMED tells us "I better do something about that bug". > > Boils down to the Q "Which criteria define a bug report status and which > criteria are expressed by other means than a status?" I don't know either. > I remember the idea of Mozilla's bugmaster to introduce a ''READY'' status. In > my opinion that status resembles the practice of KDE and Mageia having > ''triaged'' keywords, and Red Hat having ''Triaged'' and ''Unconfirmed'' > keywords instead of potentially using a status for this (the ''Triaged'' > keyword is added when a report has correct and enough data, according to > https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow ). Mozilla bugzilla seems like something to aspire to imho. I have not really spent much time with it but the time I did spend I learned I liked pretty much everything about it especially the bug entry form layout as well as the "look and feel". Very clever!
Looks like this is bug 138046 in the end *** This bug has been marked as a duplicate of bug 138046 ***