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? > 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." > 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. > The last question is about the "Opinion" and "Wont Fix" statuses, > which sound redundant to me, unless someone can suggest a good > distinction between them ? Haven't needed them yet, so not sure. > The remaining statuses are no-brainers, I think: "New" is the first > state, "Incomplete" is when it's missing input from the OP, and "In > progress" is when the assignee is working on it. 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. 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. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ OpenStack Developer http://www.openstack.org/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
