Adam Williamson wrote:
I just got a bit inspired by a QA meeting discussion, and have made substantial revisions to https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow ....
So here's a question I've asked before (a couple months ago), but it really seems worth asking again.
What happens when QA on a MODIFIED report fails? Shouldn't there be a path to send it back to ASSIGNED for rework? I do know that RH BZ currently doesn't allow it. So as a reporter, the only thing I can do if a proposed patch fails my retest is CLOSE the report. Doesn't that workflow seem broken by design?
Allen Kistler an037-ooai8@yahoo.com writes:
What happens when QA on a MODIFIED report fails? Shouldn't there be a path to send it back to ASSIGNED for rework? I do know that RH BZ currently doesn't allow it.
According to the status help page https://bugzilla.redhat.com/page.cgi?id=fields.html#status you push it to FAILS_QA, and then it goes back to ASSIGNED if the breakage is bad enough to require a new round of bug investigation.
If the ON_QA state isn't meaningful for Fedora then this state machine probably needs some adjustment for that, but it's not insane on its own terms.
regards, tom lane
On Thu, 2009-05-07 at 01:43 -0400, Tom Lane wrote:
Allen Kistler an037-ooai8@yahoo.com writes:
What happens when QA on a MODIFIED report fails? Shouldn't there be a path to send it back to ASSIGNED for rework? I do know that RH BZ currently doesn't allow it.
According to the status help page https://bugzilla.redhat.com/page.cgi?id=fields.html#status
Which, as I mentioned, is for RHEL, where there are real paid people plugged into this process...
you push it to FAILS_QA, and then it goes back to ASSIGNED if the breakage is bad enough to require a new round of bug investigation.
...this is the bit where the magic happens. "It goes back" seems to equal "maintainer sets it back".
If the ON_QA state isn't meaningful for Fedora then this state machine probably needs some adjustment for that, but it's not insane on its own terms.
The ON_QA / FAILS_QA loop doesn't make too much sense for Fedora as there is no paid QA group wired into this loop. 'QA' is the reporter.
I think it should just be a simple setup as the reporter describes; reporters should be allowed to set bugs back to ASSIGNED from MODIFIED.
At present I'd say you should just post a comment to say the fix doesn't work for you. It's then the maintainer's responsibility to change back to ASSIGNED and fix the fix.
On Thu, 2009-05-07 at 08:39 -0700, Adam Williamson wrote:
If the ON_QA state isn't meaningful for Fedora then this state machine probably needs some adjustment for that, but it's not insane on its own terms.
The ON_QA / FAILS_QA loop doesn't make too much sense for Fedora as there is no paid QA group wired into this loop. 'QA' is the reporter.
I think it should just be a simple setup as the reporter describes; reporters should be allowed to set bugs back to ASSIGNED from MODIFIED.
Ug, sorry - I'm thinking too much about Rawhide here. The ON_QA loop is of course used for Fedora in stable release updates.
I think the question comes down to "should the onus / ability to return a bug to ASSIGNED when it fails testing be on the reporter or maintainer or both". Thoughts?