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?
Tom, can you raise this issue with the appropriate Fedora folks to get a consensus on any require changes to Bugzilla?
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.
(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?
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).
+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".
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.
(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.
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
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 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.
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).
(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.
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!
I presume this should only change for bugs under the Fedora classification?
Yes.
(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.
I came here after I didn't manage to reopen https://bugzilla.redhat.com/show_bug.cgi?id=2001386 and I really don't see a way to change version or reopen that bug. When I try to change status from CLOSED to ASSIGNED I get the error "Version '34' is inactive on product 'Fedora'. You must select an active version." but I don't see any way to select active version. What am I missing?