Bug 974565 - Allow reopening bugs into POST, MODIFIED and ON_QA (in addition to ASSIGNED)
Allow reopening bugs into POST, MODIFIED and ON_QA (in addition to ASSIGNED)
Status: CLOSED CURRENTRELEASE
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs (Show other bugs)
4.4
Unspecified Unspecified
medium Severity medium (vote)
: ---
: ---
Assigned To: Simon Green
tools-bugs
:
Depends On:
Blocks: 1016357
  Show dependency treegraph
 
Reported: 2013-06-14 08:51 EDT by Cole Robinson
Modified: 2014-10-12 18:51 EDT (History)
5 users (show)

See Also:
Fixed In Version: 4.4.0009
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1016357 (view as bug list)
Environment:
Last Closed: 2013-10-03 20:45:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Cole Robinson 2013-06-14 08:51:31 EDT
I don't quite get why reopening a closed bug only allows moving it to the ASSIGNED state. I've seen several scenarios where it just creates a needless extra step:

- Developer closes a bug in NEW state for any number of reasons, reporter reopens bug for any number of reasons, and it's now ASSIGNED to the developer which may not match their particular workflow.

- Bug is closed, but I want to reopen it and move it to a different component. Doing so sets the state to ASSIGNED for some random developer which may not match their particular workflow.

- Bug is closed as say INSUFFICIENT_DATA or CANTFIX, but then a fix is discovered. Want to reopen the bug and set it to POST to indicate theirs a patch pending or something similar.

Obviously I can work around this by doing an extra step to change the status afterwards, but it's unneeded effort IMO. Given that bugzilla doesn't seem to enforce a particular bug state workflow elsewhere in the UI, it seems doubly awkward.

I do see this bug: https://bugzilla.redhat.com/show_bug.cgi?id=950683  but that guy is saying once a bug is reopened he can only set state to ASSIGNED or CLOSED which isn't what I'm seeing, maybe that behavior depends on if you're a RH dev or Fedora package owner or something.
Comment 1 Simon Green 2013-06-16 21:52:54 EDT
(In reply to Cole Robinson from comment #0)
> I don't quite get why reopening a closed bug only allows moving it to the
> ASSIGNED state. I've seen several scenarios where it just creates a needless
> extra step:
> 
> - Developer closes a bug in NEW state for any number of reasons, reporter
> reopens bug for any number of reasons, and it's now ASSIGNED to the
> developer which may not match their particular workflow.

I will add the NEW option, since it makes sense to be able to do this (i.e. to signify that it has not be assigned).

> - Bug is closed as say INSUFFICIENT_DATA or CANTFIX, but then a fix is
> discovered. Want to reopen the bug and set it to POST to indicate theirs a
> patch pending or something similar.

However, all options passed ASSIGNED should be marked as ASSIGNED first. I would imagine it is some time between the bug being re-opened and a patch being submitted. Even if not, I think it is worthwhile having the extra step, in terms of acknowledging that it has been assigned.

> I do see this bug: https://bugzilla.redhat.com/show_bug.cgi?id=950683  but
> that guy is saying once a bug is reopened he can only set state to ASSIGNED
> or CLOSED which isn't what I'm seeing, maybe that behavior depends on if
> you're a RH dev or Fedora package owner or something.

That is correct for some products.

  -- simon
Comment 2 Cole Robinson 2013-06-17 07:52:40 EDT
Thanks for looking at this Simon.

> 
> > - Bug is closed as say INSUFFICIENT_DATA or CANTFIX, but then a fix is
> > discovered. Want to reopen the bug and set it to POST to indicate theirs a
> > patch pending or something similar.
> 
> However, all options passed ASSIGNED should be marked as ASSIGNED first. I
> would imagine it is some time between the bug being re-opened and a patch
> being submitted. Even if not, I think it is worthwhile having the extra
> step, in terms of acknowledging that it has been assigned.
> 

I think that's pretty arbitrary. Plenty of times I've closed a bug as INSUFFICIENT_DATA because a reporter never responded to NEEDINFO, yet later the bug was fixed upstream. Depending on when the bug is identified, I might want to go to MODIFIED/ON_QA/RELEASE_PENDING if it was fixed in a build, or POST, which we use in Fedora virt to mean 'patch has been committed upstream' to remind the maintainer what patches to include in the next build.

IMO any state change allowed by NEW->XXX should be allowed for CLOSED->XXX
Comment 3 Cole Robinson 2013-06-18 19:13:23 EDT
Here's an example I just hit where I wanted to go from CLOSED->POST. Bug was closed CANTFIX, discussion continued, someone identified the bug and posted a patch but didn't reopen, I wanted to reopen it right to POST.

https://bugzilla.redhat.com/show_bug.cgi?id=974804
Comment 5 Simon Green 2013-07-23 19:31:23 EDT
Hi Jason,

I need your opinion on this bug. Should this bug be implemented, and what states should a CLOSED bug be allowed to be set to?
Comment 6 Jason McDonald 2013-07-26 01:01:57 EDT
Before I feel confident to recommend a change, I'd like to understand how and why we arrived at the current state and whether any stakeholders are relying on the current behaviour.

Note that it is important to remember that for bugs that have had a solution shipped, one should generally raise a new bug rather than reopening the original one if it turns out that further work is required.  Therefore, I'm treating this discussion as only being about the workflow for bugs that have been closed without shipping a fix.

From looking into the source code history in git and svn, I can see that the current behaviour is a Red Hat customization -- in the upstream Bugzilla, CLOSED can transition to either UNCONFIRMED or REOPENED states, neither of which RH seems to be using.

The present RH-specific restriction on the transitions appears to have been introduced on May 25, 2010 by dkl@redhat.com in a commit entitled "extensions/RedHatFields now simply called extensions/RedHat".  Unfortunately, the commit does more than just the renaming that the description suggests and it does not cite any bug numbers or requirements that might explain why the change was introduced.

I'm happy to support the suggestion to allow CLOSED to transition to NEW (in addition to ASSIGNED).  Particularly with several RH internal teams moving to Scrum, I envisage that there will be times when a bug is reopened (because it turns out to be a valid bug), but isn't going to be worked on immediately (and therefore doesn't belong in ASSIGNED).

Perhaps it would be appropriate to split that suggestion into a separate bug report and keep this one for the suggestion to allow transitions from CLOSED to states beyond ASSIGNED, which I expect is going to be more controversial.

I will consult with EIP and releng to determine whether they see any need for the current restriction to stay in place. Once I have that information I will post another update here.
Comment 7 Jason McDonald 2013-08-28 23:51:49 EDT
I ran this proposal by aj recently and he didn't have a problem with it.  Can we get a response from EIP and CDW folks too?
Comment 8 Suzanne Yeghiayan 2013-08-29 15:31:22 EDT
So ... I'm okay with adding more states to be set from a CLOSED bug.

I am however against adding NEW since the bug is clearly not new.  The VERIFIED state is reserved for only QE.  And RELEASE_PENDING is reserved for only RCM.  I'd leave these three states out of this change.

In addition to current option of the ASSIGNED state, I'm for adding POST, MODIFIED and ON_QA.

My two cents ...
Comment 9 Edward Rousseau 2013-08-30 10:27:04 EDT
I think Sly's comments obove cover my feelings on this. It would be good just to run it past the ET Dev to check if the changes affect thier workflow in any way.
Comment 10 Jason McDonald 2013-09-02 01:46:54 EDT
Ok, let's add this to the backlog (allowing CLOSED to transition to POST, MODIFIED and ON_QA in addition to ASSIGNED) and we'll talk about CLOSED->NEW separately as part of my upcoming CDW 2.0 interview.
Comment 12 Cole Robinson 2013-10-02 09:23:58 EDT
(In reply to Suzanne Yeghiayan from comment #8)
> So ... I'm okay with adding more states to be set from a CLOSED bug.
> 
> I am however against adding NEW since the bug is clearly not new.

You can't make that assumption though. The bug could change state 5000 times without the bug owner ever looking at it: to the person who's responsibility it is it's still most definitely NEW.

And the problem with assuming 'NEW' means what it says is that you have to be fair and assume "ASSIGNED" means what it says. And when $user reopens a 5 year old bug and it gets automatically assinged to a catchall address like virt-maint@fedoraproject.org, what does that mean? Someone on the other end of that list is actively paying attention to it? We know better, but not $user. In that way, having closed->assigned be the default actually dilutes whatever meaning assigned already has.
Comment 13 Jason McDonald 2013-10-02 21:11:46 EDT
For projects that aren't using CDW (e.g. internal projects using Scrum), NEW means any state before "someone has started working on this". ASSIGNED is typically used as "In Progress" because we're discouraged from using ON_DEV for that.

Every time I've reopened a bug on one of those projects, NEW has always been the state that I wanted to get the bug into, because by reopening the bug I was simply confirming that the bug was determined to be valid (and therefore adding it into the project backlog) rather than assigning someone to begin work on it right now.
Comment 14 Simon Green 2013-10-03 20:45:28 EDT
This change is now live. If there are any issues, do not reopen this bug.
Instead, you should create a new bug and reference this bug.

  -- simon
Comment 15 Suzanne Yeghiayan 2013-10-07 15:35:58 EDT
Jason, you have made me see the light with comment 13.  Please open a new bug report requesting the addition of NEW to the reopened status list.

Note You need to log in before you can comment on or make changes to this bug.