On Wed, Nov 24, 2010 at 7:46 AM, Soren Hansen <so...@openstack.org> wrote: > 2010/11/24 Thierry Carrez <thie...@openstack.org>: >> The first question is what "Fix committed" and "Fix released" should >> mean. There are two possible directions: >> >> * The developer (or "trunk") view, where "Fix committed" means a branch >> has been proposed with the fix, and "Fix released" means the fix has >> landed in trunk. >> >> * The user (or "release") view, where "Fix committed" means the fix has >> been committed to trunk and "Fix released" means the fix has been >> released in a given "Openstack release". >> >> Given the way LP handles "Fix committed" bugs (keep them visible by >> default in bug lists), I tend to prefer the "developer/trunk" view, but >> maybe that is confusing for users (makes it a bit more difficult to find >> already-fixed-in-trunk duplicates when filing a bug against a released >> version ?). > > Is this really a question about whether the bug tracker is a tool for, > developers to manage bugs or a communication tool between developers and > "users"? If so, can we get rid of this dichotomy somehow?
I actually prefer the "user-centric" view because it relates to a "release". >> The second question revolves around the "Confirmed" and "Triaged" >> states. I would use "Confirmed" when the bug has been acknowledged as >> a real bug and had its "Importance" set. Or should we restrict it to >> bugs that have been strictly reproduced ? > > I've set bugs to confirmed once I've decided that it's likely an actual > bug. This may include reproducing it or just looking at it and going > "oh, yeah, I totally believe that could happen." To me, Reproducible == Confirmed. >> Then I would use "Triaged" when the bug is understood (we know how to >> fix it, it is ready to be fixed), but just missing an assignee with >> time to fix it. Would that be reasonable ? Would you prefer some other >> meaning ? > > Recently, I've set bugs to "Triaged" once I've spent enough time looking > at it that I believe I know how to fix it and I feel I've put enough > information into the bug that I (or someone else!) could start writing > the code. That seems like a good pattern to me. That way, if I'm in a > coding mood, I can just go to the bug tracker and work on those, while > I'm in more of a debugging mood, I can look at the confirmed ones. I don't really see a need for Triaged at all...that's what the bug priority/importance is for. > I'd also like to talk about the specific meaning of the importance field > to make it less random. Something like: > > Critical > -------- > > * More than a few people are likely to lose data, or > * render some component of OpenStack completely unable to run anywhere, > or > * leaks sensitive information or lets an attacker alter information. And does NOT have a workaround. No bug is critical, IMHO, if there is a valid workaround. > High > ---- > > * Makes some component of Openstack unable to run in most configurations. > * Exposes a component of OpenStack to DoS attacks. > > etc. > > > This would make these importance settings much more useful. Agreed. Some other things to consider in assigning a bug's importance: * Number of people affected by the bug. For instance, if the bug only affects Mac users or only CentOS users, should not rank as highly as others that affect everyone * Does it corrupt a datastore? If yes, bump up priority -jay _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
