On 07/29/2014 11:48 AM, Russell Bryant wrote:
On 07/29/2014 11:43 AM, Tracy Jones wrote:
3. We have bugs that are really not bugs but features, or performance
issues. They really should be a BP not a bug, but we don’t want these
things to fall off the radar so they are bugs… But we don’t really know
what to do with them. Should they be closed? Should they have a
different category – like feature request?? Perhaps they should just be
wish list??
I don't think blueprint are appropriate for tracking requests. They
should only be created when someone is proposing actually doing the work.
I think Wishlist is fine for keeping a list of requests. That's what
I've been using it for.
There's a metric crap-ton of bugs that are *not* in Wishlist and are
instead in High or Medium importance, but they are not necessarily bugs
that either have a specific solution -- see: performance-related bugs --
or are things that frankly can never be "fixed".
We don't want to keep these things as bugs, because they aren't really
bugs, but the blueprint/spec stuff isn't appropriate for "epics" that
are like super-specs to be used to track general themes. We think that a
separate category of thing is needed for tracking these themes. In
Agile, these things are called "epics".
In generate we need to tighten up the definition of triaged and
confirmed. Bugs should move from New -> Confirmed -> Triaged -> In
Progress. JayPipes has updated the wiki to clarify this.
* Confirmed means someone has looked at the bug, saw there was enough
into to start to diagnose, and agreed it sounds like a bug.
* Triaged means someone has analyzed the bug and can propose a
solution (not necessarily a patch). If the person is not going to
fix it, they should update the bug with the proposal and move the
bug into Triaged.
We should be careful not to conflict with the guidelines set for all
OpenStack projects here:
https://wiki.openstack.org/wiki/BugTriage
For example, that page says when a bug should be set to Confirmed or
Triaged. In most cases, it's Confirmed. Triage is when there is a
known solution.
So, yeah, we went back and forth on this. One thing that was mentioned
is that by setting something to Wishlist from, say, High, we downplay
the importance of the particular "bug", which, for performance and
scalability "epics" tends to annoy both the bug submitter and the bug owner.
However, setting the bug to New, which triggers a re-verification and/or
re-triaging of the issue, puts the onus and responsibility on the bug
triaging team and allows the bug to be taken off of the "In progress but
Abandoned" list and not lost into the general swamp of "In progress but
not assigned".
Anyway, just food for thought.
-jay
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
