Comment 7 for bug 297614

Matthew Paul Thomas wrote:
> I don't think having a "Fix Verified" status is a bad idea per se, but
> every extra bug status makes Launchpad harder to understand (q.v. bug
> 29495), even for projects that never use it. (Launchpad Bugs currently
> has nine bug statuses, three of which are useless for most projects.)

I'm not sure I see that as a very good argument - i.e., "we already
implemented useless states, so don't want to add any more states whether
they are useful or useless"! ;)

> What would "Fix Failed" be used for as distinct from
> "Confirmed"/"Triaged"? (I know what it would mean, I'm asking what it
> would be used for.)
>
>

It would be used to know a bug's actual status in the workflow - i.e.,
that a fix has been tried and didn't work. When you consider that at
any given time there are lots of bugs that are confirmed but don't have
a fix attempted for them yet, it's useful to have a different state for
those that have had a fix attempted. When this is done with tags, you
then have 2 data elements to manage for the rest of the workfloe. As it
is re-fixed and iterates through the workflow again, you have to manage
bug status and edit/remove tags in order to represent bug status - i.e.,
we're representing the same thing (status) in two different and unlinked
ways (status and tags). In my view, FixVerified and FixFailed (or
similar) are discrete steps in most project's workflow, and should be
represented as discrete status values.

But I also suggest that a wider view should be taken on this. I know
Launchpad serves many customers, but the primary ones (at least at this
stage) are Ubuntu and Canonical (i.e,. our private projects). Perhaps a
survey of the Ubuntu, Landscape, Online Services, OEM Services, etc team
would help shed light on what LP users actual requirements are on this
particular topic? (I.e,. I don't presume to speak for all of them, just
as I'm sure LP devs don't.)