Bug 1028145 - behavior with closed Fedora EOL bugs leads to worse user experience than intended
behavior with closed Fedora EOL bugs leads to worse user experience than inte...
Status: CLOSED WORKSFORME
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs (Show other bugs)
4.4
Unspecified Unspecified
unspecified Severity high (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
tools-bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-07 13:38 EST by Matthew Miller
Modified: 2013-11-24 18:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-24 18:07:19 EST
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 Matthew Miller 2013-11-07 13:38:33 EST
Phenomenon
----------

The Fedora bugzilla end of life message says

> If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version.

However, bug reporters without special permissions cannot change versions nor reopen the bug when that bug belongs to an end of life release. This leads to a much worse user experience than the intention with the auto-closing of bugs.

Users may comment "please reopen", but it's more likely than average for bugs which got no response to also get no response to this, leading to strong user frustration.

Note that normal users can reopen their reported bugs marked CLOSED:WONTFIX in current releases. (And Fedora packagers have greater permissions.)
reason

Background
----------

I don't think this was always the case, although I found a ​short thread apparently discussing this in 2010. The (quite old) ​bugzappers EOL wiki page says "In the future we will seek an enhancement to bugzilla to disable the ability to file bugs against unmaintained versions as there is no value in doing so." This is now the case, and it is possible that this behavior is an unintended consequence of that change.
recommendation

This is pretty awful. If we hadn't, apparently, had this problem for so long, I'd go with Sky is Falling as severity. I hadn't noticed because, like most active Fedora developers, I have higher privileges. 

Request
-------

Could you please add the option for all users to re-version and reopen bugs closed against older Fedora versions?
Comment 1 Jason McDonald 2013-11-07 18:57:06 EST
Tom, can you raise this issue with the appropriate Fedora folks to get a consensus on any require changes to Bugzilla?
Comment 2 Jaroslav Reznik 2013-11-08 04:43:32 EST
Hi Jason,
I own the EOL process in Fedora. Previously, we asked reporters to use cloning to reopen bug for the new version - see https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora18#Comment_Text_2 - but many developers were complaining that clone should not be used, so we changed the wording. But as Matt mentioned - without the knowledge that users are not allowed to do same action we are.

So we have two options now:
1. go back to the former workflow using Clone a bug
2. be less strict as requested but I'd like to know how it will affect maintainers (people spuriously opening bugs, even not EOL ones...)

Or combination - specifically kernel guys asked to opt out from "Clone a bug", they are known for well triaged Bugzilla, so a different wording "ask maintainer to rebase" for them could work too.

I'm open to all options, third means more work for me but sounds like a good compromise (unless more teams ask for opt-out)...

I'd like to see ratification from FESCo for any further Bugzilla changes.
Comment 3 Matthew Miller 2013-11-08 08:16:31 EST
(In reply to Jaroslav Reznik from comment #2)
> 2. be less strict as requested but I'd like to know how it will affect
> maintainers (people spuriously opening bugs, even not EOL ones...)

Note that people _can_ reopen bugs that are not EOL already. I confirmed this with a new test account.


> I'd like to see ratification from FESCo for any further Bugzilla changes.

Do you want to file a FESCo meeting ticket, or should I?
Comment 4 Kevin Fenzi 2013-11-08 10:32:47 EST
Well, before we go to fesco, could we find out a few more things?

Is it possible to tweak bugzilla so: 

- Reporter can reopen a bug against a closed release
- But as part of that reopen the version is changed to a newer release that is open for bugs

Or is that not possible? 

If figuring out what version(s) are open is difficult, could the reopened bug just be switched to 'rawhide' (which is always open).
Comment 5 Matthew Miller 2013-11-08 10:48:54 EST
+1 to Kevin's suggestion above.

In combination with that, we should add a comment on what to do if you have the problem but are _not_ the original reporter.

Another possibility would be to change our workflow so that EOL bugs are marked as NEEDINFO rather than closed.  (See earlier bug #528319) That has several benefits:

1. Solves this problem (I think; need to test to make sure that flag can be cleared on EOL bugs.)

2. Allows us to distinguish _intentional_ WONTFIX from EOL bugs.

3. Allows us to make a positive announcement of "we know people hate the closing of bugs thing; we hear that as a strong valid complaint and are adjusting the workflow".
Comment 6 Kevin Fenzi 2013-11-08 11:38:38 EST
I kinda hate that. :) It means that these EOL needinfo bugs will show up on my frontpage or open bug reports forever. If we want to do that, we should definitely get FESCo approval.
Comment 7 Matthew Miller 2013-11-08 13:19:03 EST
(In reply to Kevin Fenzi from comment #6)
> I kinda hate that. :) It means that these EOL needinfo bugs will show up on
> my frontpage or open bug reports forever. If we want to do that, we should
> definitely get FESCo approval.

Change your bug reports to exclude NEEDINFO by default; make a separate report for that.

We could also have a grace period and have NEEDINFO bugs which weren't responded to in a certain amount of time (say, the next release) automatically closed as INSUFFICIENT_DATA.
Comment 8 Matthew Miller 2013-11-09 19:08:28 EST
FESCo ticket -- I'm going to suggest the NEEDINFO workflow proposed above, but if that doesn't go through, come back with at least *some* decision.

https://fedorahosted.org/fesco/ticket/1198
Comment 9 Jaroslav Reznik 2013-11-11 08:55:15 EST
Well, we already have this NEEDINFO workflow. Bugs are closed in two pass way - first, reminder is sent, NEEDINFO is set, so reporters has one month to react before bug is closed.
Comment 10 Matthew Miller 2013-11-11 11:37:50 EST
(In reply to Jaroslav Reznik from comment #9)
> Well, we already have this NEEDINFO workflow. Bugs are closed in two pass
> way - first, reminder is sent, NEEDINFO is set, so reporters has one month
> to react before bug is closed.

In that case, I guess the change is to keep the NEEDINFO there for much longer.
Comment 11 Jaroslav Reznik 2013-11-15 04:01:41 EST
Jason,
this bug was discussed at the Wednesday's FESCo meeting and they would like to hear, if it is possible to change Bugzilla settings to allow reporters to reopen and re-version closed bugs for EOLed release (as suggested in the first comment by Matt).
Comment 12 Simon Green 2013-11-15 06:00:06 EST
(In reply to Jaroslav Reznik from comment #11)
>if it is possible to change Bugzilla settings to allow reporters to
> reopen and re-version closed bugs for EOLed release (as suggested in the
> first comment by Matt).

Yes, it is possible.
Comment 13 Matthew Miller 2013-11-20 13:21:57 EST
Jason, Simon -- Fesco has agreed that we would like the change above (reporters can reopen and re-version closed bugs for an EOLed release). Thanks!
Comment 14 Jason McDonald 2013-11-22 00:57:02 EST
I presume this should only change for bugs under the Fedora classification?
Comment 15 Kevin Fenzi 2013-11-22 10:54:08 EST
Yes.
Comment 16 Simon Green 2013-11-24 18:07:19 EST
(In reply to Matthew Miller from comment #13)
> Jason, Simon -- Fesco has agreed that we would like the change above
> (reporters can reopen and re-version closed bugs for an EOLed release).
> Thanks!

This functionality already exists. See these three examples of where the reporter reopened a closed bug in an EOL version.

https://bugzilla.redhat.com/show_bug.cgi?id=720139#c4
https://bugzilla.redhat.com/show_bug.cgi?id=871360#c8
https://bugzilla.redhat.com/show_bug.cgi?id=514836#c9

In all cases, the reporter had no group privileges, and were able to reopen the bug with an expired version. The reporter also has the ability to change the version at any time.

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