openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Wed, Nov 24, 2010 at 7:46 AM, Soren Hansen <soren@xxxxxxxxxxxxx> wrote:
> 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?

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