Launchpad itself

Bug #297614
Comment #3

Comment 3 for bug 297614

Revision history for this message

Joey Stanford (joey) wrote on 2008-11-13: Re: Add a FixVerified and FixFailed bug status

I've changed this bug to private so I can include some additional information from an offline conversation:

That is what is exactly what is being done now, but it causes unnecessary stress and confusion. Can't you have a critical bug that also has a workaround? The workaround isn't sufficient because (in no particular order)

a.) the lack of a verification status in our standard bug flow alarms customers. QA is an important stage, and a fix that has been verified or failed does actually put the bug in a different state. Having it represented by a state is just the right thing to do (imho). I suspect this isn't just an OEM team request.

b.) the tags are too loose, and too subject to error. We end up with bugs that are in a FixCommitted state with both verify and verifyfailed tags (and of course there is nothing in the system to avoid tags that should be logically exclusive). Or even at the end of the process with a FixReleased bug and a verify-failed tag. Yes, more education and discipline could solve some of this, but that's back to the unnecessary stress and confusion, when you consider explaining to a customer and their far-flung QA teams why this important part of the workflow (QA) is represented in our system by what is clearly a workaround.

c.) tags don't work well in part because of some of the other bugs I filed (e.g, the fixed columns in a bug list). You can search for a tag, but for example you can't see a list of FixCommitted bugs and easily identify (or even sort by) which ones have what verification tags. Yes, you can do this in separate searches (but again there are bugs about not being able to see what search criteria have been applied or not being able to save searches), so you end up with different tabs that both have FixCommitted bugs and you have to remember what search you did in what tab. The entire workflow is just a bunch of workarounds that feel very unpleasant and clunky.

I think the bottom line is that tags are an awkward workaround, and then they are made even more awkward by the limitations in searching/reporting.

I've changed this bug to private so I can include some additional information from an offline conversation:

That is what is exactly what is being done now, but it causes unnecessary stress and confusion.  Can't you have a critical bug that also has a workaround? The workaround isn't sufficient because (in no particular order)

a.) the lack of a verification status in our standard bug flow alarms customers.  QA is an important stage, and a fix that has been verified or failed does actually put the bug in a different state. Having it represented by a state is just the right thing to do (imho). I suspect this isn't just an OEM team request.

b.) the tags are too loose, and too subject to error.  We end up with bugs that are in a FixCommitted state with both verify and verifyfailed tags (and of course there is nothing in the system to avoid tags that should be logically exclusive).  Or even at the end of the process with a FixReleased bug and a verify-failed tag. Yes, more education and discipline could solve some of this, but that's back to the unnecessary stress and confusion, when you consider explaining to a customer and their far-flung QA teams why this important part of the workflow (QA) is represented in our system by what is clearly a workaround.

c.) tags don't work well in part because of some of the other bugs I filed (e.g, the fixed columns in a bug list).  You can search for a tag, but for example you can't see a list of FixCommitted bugs and easily identify (or even sort by) which ones have what verification tags.  Yes, you can do this in separate searches (but again there are bugs about not being able to see what search criteria have been applied or not being able to save searches), so you end up with different tabs that both have FixCommitted bugs and you have to remember what search you did in what tab.  The entire workflow is just a bunch of workarounds that feel very unpleasant and clunky.

I think the bottom line is that tags are an awkward workaround, and then they are made even more awkward by the limitations in searching/reporting.