openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxxxx>]

2010/11/24 Thierry Carrez <thierry@xxxxxxxxxxxxx>:
> 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/