#1198 Possible changes to Fedora EOL bug procedure
Closed None Opened 10 years ago by mattdm.

Background https://bugzilla.redhat.com/show_bug.cgi?id=1028145

In short, the auto-close message tells people to reopen if it's still an issue, but regular users (even the bug reporter) can't make the necessary changes.

I've been asking a lot of people what they like and do not like about Fedora, and the auto-closing is up there in the top ten (on the second of those lists).

When I started doing this in 2005 or whenever, the idea was to help sort out bugs that were still real and important to people from years of legacy cruft filed against Red Hat Linux. The process I used was NEEDINFO for a month and then to WONTFIX for the ones that weren't touched.

Also I added myself to the CC list of all the bugs I closed in this way and attempted to respond personally when people had issues. And I did it by hand rather than having it scripted. Things were smaller then. :)

I really still like that two-phase approach, because I think it sends a better message. The current one is really disheartening to users. And, it distinguishes intentional WONTFIX from scripted closure. (I'd even suggest INSUFFICENT_DATA as the final state. Travel with me now down [http://www.redhat.com/archives/fedora-maintainers/2005-May/msg00146.html memory lane ]...)

I think this has the advantage of not requiring any bugzilla changes. I also like it as an opportunity to note to people that we are doing more than just fixing the bug but trying to make the overall process less harsh to users who contribute their feedback.

If we can't get agreement on that, we should ask for the bugzilla change so (at least) the requester can reopen their own bugs.


Replying to [ticket:1198 mattdm]:

Background https://bugzilla.redhat.com/show_bug.cgi?id=1028145

In short, the auto-close message tells people to reopen if it's still an issue, but regular users (even the bug reporter) can't make the necessary changes.

This happened one release back when I was asked to change the process from Clone a bug to reopen and unfortunately nobody was aware of this issue that time. There are two options - go back to Clone a bug but many maintainers are not comfortable with it or allow regular users to reopen and rebase bugs as mentioned in BZ above.

I've been asking a lot of people what they like and do not like about Fedora, and the auto-closing is up there in the top ten (on the second of those lists).

Unfortunately we're not able to cover and fix all bugs and some sort of clean up is needed and it of course requires cooperation from bug reporters. Sometimes, more for a curiosity, I take a look on bugs I'm closing and it makes me a bit sad (ala bugs with patch proposed) but I know we have some limits.

In Fedora 16, +/- 7300 bugs were closed. Fedora 17 was +/- 9000... For cleanup reasons, also rawhide bugs reported during the development of next Fedora are rebased to actual version (approved by FESCo).

When I started doing this in 2005 or whenever, the idea was to help sort out bugs that were still real and important to people from years of legacy cruft filed against Red Hat Linux. The process I used was NEEDINFO for a month and then to WONTFIX for the ones that weren't touched.

Also I added myself to the CC list of all the bugs I closed in this way and attempted to respond personally when people had issues. And I did it by hand rather than having it scripted. Things were smaller then. :)

I really still like that two-phase approach, because I think it sends a better message. The current one is really disheartening to users. And, it distinguishes intentional WONTFIX from scripted closure. (I'd even suggest INSUFFICENT_DATA as the final state. Travel with me now down [http://www.redhat.com/archives/fedora-maintainers/2005-May/msg00146.html memory lane ]...)

Except for the final INSUFFICENT_DATA resolution, we already have two-phase approach implemented exactly as outlined above. At first, the warning message is sent to every bug matching criteria [https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19#Fedora_17_EOL_Warning], setting the NEEDINFO flag. Now, reporters have one month to rebase bug to the new version if the issue reported still exists. After that period, bug is closed (as WONTFIX, could be changed) [https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19#Fedora_17_EOL_Closure].

I think this has the advantage of not requiring any bugzilla changes. I also like it as an opportunity to note to people that we are doing more than just fixing the bug but trying to make the overall process less harsh to users who contribute their feedback.

Definitely and it's the way how the process is set up. Except that unfortunate problem with reopening already closed bugs but reporters has one month to react in standard way.

If we can't get agreement on that, we should ask for the bugzilla change so (at least) the requester can reopen their own bugs.

Still there's that option to go back to Clone a bug mentioned above. Or this, I'm ok with both, maintainers I talked to are more inclined to the second way - so BZ change will be needed.

AGREED: defer a week and get more input from bz team. (+8,0,0) (nirik, 19:18:01)

Uh, as far as I know, reporters '''can''' reopen bugs in our Bugzilla, in fact one reporter (who I think is not a Fedora / Red Hat developer) just did that a few hours ago.

Oh, according to the linked bug, it does not work for bugs filed against EOL releases? Even if they change both the bug state and Version in one step? Then that's a clearcut bug in our Bugzilla setup and needs to be fixed there.

Replying to [comment:4 kkofler]:

Oh, according to the linked bug, it does not work for bugs filed against EOL releases? Even if they change both the bug state and Version in one step?

Right -- they aren't even offered the option. (The controls to do it aren't show.)

The answer from Simon Green is - it's possible to allow rebasing and reopening of bugs for EOLed versions, see https://bugzilla.redhat.com/show_bug.cgi?id=1028145#c12

+1 to making that change in bugzilla then.

  • AGREED: Ask the Bugzilla administrators to implement the reopen-and-re-version request (+8, 0, -0) (sgallagh, 18:20:21)

Seems like it's already implemented this way - https://bugzilla.redhat.com/show_bug.cgi?id=1028145#c16 - maybe we should ask someone without privileges to try to reopen closed bug for eoled version...

I will retest. I had someone right in front of me showing me the problem, and I could replicate similar behavior with a dummy account (although it's hard to test since I can't open new bugs against EOL releases.)

Defer for a next week, mattdm needs to test it again (mmaslano, 18:17:28)

I still need to work on this -- deferring again.

As a process note, the EOL SOP:

https://fedoraproject.org/wiki/End_of_life_SOP

lists this as a Bugzappers responsibility:

" Bugzappers Tasks

Close all open bugs
End of life process "

With the death of Bugzappers, it may perhaps be logical to consider it a part of QA's domain, though I think jreznik or someone has been taking care of actually getting EOL run, lately. But it seems slightly odd for FESCo to be dealing with EOL change proposals without apparently running it by any other stakeholders.

@mattdm -- news on this or should we defer again?

Let's defer again. Too much other stuff going on. Will make sure to get to it before the next big close.

And, Adam -- sorry! Not meaning to ask for any big changes with involving the stakeholders.

Replying to [comment:13 adamwill]:

As a process note, the EOL SOP:

https://fedoraproject.org/wiki/End_of_life_SOP

lists this as a Bugzappers responsibility:

" Bugzappers Tasks

Close all open bugs
End of life process "

With the death of Bugzappers, it may perhaps be logical to consider it a part of QA's domain, though I think jreznik or someone has been taking care of actually getting EOL run, lately. But it seems slightly odd for FESCo to be dealing with EOL change proposals without apparently running it by any other stakeholders.

Adam,
yes, Robyn/Spot hand it over to me. I'm trying to follow up with all other Bugzappers House Cleaning stuff for releases - https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20 as it's usually PGM task (as for all other project in my team). I'm involved in the discussion and so far, I think we're not planning any important changes to process (it's my understanding from discussion). But I'm definitely ok with any proposals coming from other teams and QA feedback is more then welcomed.

Replying to [comment:15 mattdm]:

Let's defer again. Too much other stuff going on. Will make sure to get to it before the next big close.

We can't defer it now as Fedora 20 was released and EOL warning should be send asap. So we don't have much time now (not to make reporters feel bad with unnoticed closure). Anyone is able to check if non privileged users are able to reopen theirs bugs? If so, I think at least for F18 EOL it should be enough now. We can discuss possible changes to process together with multiple products proposal.

Please, add this topic to the today's meeting (I'll try to join - probably from phone - unfortunately).

Okay -- I'm in meetings this morning but will try to recreate my test.

Wouldn't be better to do some huge change for new products after this release?

FESCo voted to send warning now, gather more info and revisit before sending close/closing. Passed (+1: 6, 0:0, -1:0)

action mattdm to verify that reopening works before it's time to close the EOL bugs.

We also mentioned that we're not looking to do any big changes to this at this time. We just want re-opening to work or to adjust the wording of the close message if it doesn't work.

FYI, EOL warning processed on 2013-12-22.

For the record, QA group discussed the EOL process topic at our weekly meeting today:

http://meetbot.fedoraproject.org/fedora-meeting/2014-01-13/fedora-qa.2014-01-13-16.00.html

We did note that the procedure of closing bugs at EOL originated as part of the Bugzappers effort, with poelcat wearing his 'bugzappers hat', not his 'program manager hat':

http://johnpoelstra.com/five-months-of-bug-triage/

but overall most group members were fine with the Bugzilla part of the EOL process being a responsibility of the program manager, so long as it's backed by an SOP and there is a process for suggesting improvements to the way it's done.

We note that the general EOL SOP:

https://fedoraproject.org/wiki/End_of_life_SOP

lists the bug closure as a responsibility of 'Bugzappers', which needs changing one way or another now that group is dead, and it would be good to move the process documentation out of the Bugzappers space on the Wiki if possible to clarify things also.

Johann has a somewhat different take on the topic, which I'm sure he can append as a separate comment. If anyone wants to check the accuracy of my summary above, please do refer to the complete meeting logs.

It is getting pretty close to the time we need to know if non-privileged users can re-open EOL bugs, too, I'd note.

Fedora 18 EOL is today. It would be nice to have final decision this week, so EOL closure script could be adjusted and run in the end of this week.

I'm willing to own this process and definitely looking for feedback and enhancements.

I swear I saw it with my own eyes, but can't reproduce or find a reproducer. So, I think we should go ahead as planned, but would like to see one of the following:

  1. Add a line like: "If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please contact bugzilla-ombudsman@fedoraproject.org." With that alias then forwarding to one or more people willing to help.

  2. Add a link to a survey about people's experience with the end of life procedure. Questions like
    * Are you the bug reporter / package owner / someone else with the same problem / other?
    * Were you able to retest this bug in current Fedora?
    * Does the problem still persist?
    * If applicable, were you able to reopen the bug?
    * Free-form rant space

I don't know if the survey is ''really'' a great idea, but I do want to give people an idea of where they can turn. Bug reports are one way in which users contribute to the project, and people should know that that's valued even for reports which don't get direct action.

As mentioned above, longer term, I'd like to see a different resolution state from WONTFIX. I think there should be one specifically reserved for auto-closed bugs. This has three advantages:

  1. It better represents that actual situation, and doesn't seem so adversarial.
  2. We can better track bugs that are in this state vs. intentional WONTFIX.
  3. We could then allow anyone (not just the reporter) to reopen these (but not bugs closed intentionally).

Oh, I guess I do have one other suggestion for a concrete change immediately -- could we change the NEEDINFO period from one month to the entire time until the next release is EOL?

Replying to [comment:26 mattdm]:

I swear I saw it with my own eyes, but can't reproduce or find a reproducer. So, I think we should go ahead as planned, but would like to see one of the following:

  1. Add a line like: "If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please contact bugzilla-ombudsman@fedoraproject.org." With that alias then forwarding to one or more people willing to help.

+1, I like it. I'm not sure how to handle that bugzilla-ombudsman email but will try to ask infra.

  1. Add a link to a survey about people's experience with the end of life procedure. Questions like
    * Are you the bug reporter / package owner / someone else with the same problem / other?
    * Were you able to retest this bug in current Fedora?
    * Does the problem still persist?
    * If applicable, were you able to reopen the bug?
    * Free-form rant space

I don't know if the survey is ''really'' a great idea, but I do want to give people an idea of where they can turn. Bug reports are one way in which users contribute to the project, and people should know that that's valued even for reports which don't get direct action.

Not sure about having this survey, at least externally to Bugzilla.

  • Were you able to retest this bug in current Fedora?
  • Does the problem still persist?

These two definitely belongs to Bugzilla.

  • If applicable, were you able to reopen the bug?

Should be handled by 1).

So I'd prefer to ask people for theirs feeling about the process in the EOL text, to be send for example to ombudsman alias. Feedback is really valuable.

As mentioned above, longer term, I'd like to see a different resolution state from WONTFIX. I think there should be one specifically reserved for auto-closed bugs. This has three advantages:

  1. It better represents that actual situation, and doesn't seem so adversarial.
  2. We can better track bugs that are in this state vs. intentional WONTFIX.
  3. We could then allow anyone (not just the reporter) to reopen these (but not bugs closed intentionally).

Johann proposed CANTFIX. Not sure if it would be possible to add another state to BZ, can recheck with BZ team, as there's push on having even less states from people owning BZ processes.

Using CANTFIX works for me. If we do that, can we remove CANTFIX from the list of statuses that Fedora packagers can set the resolution to manually? That also has the advantage of simplifying that list by a tiny bit.

Replying to [comment:29 mattdm]:

Using CANTFIX works for me. If we do that, can we remove CANTFIX from the list of statuses that Fedora packagers can set the resolution to manually? That also has the advantage of simplifying that list by a tiny bit.

Please don't do that. The kernel team uses CANTFIX for bugs that are filed against us involving closed-source drivers. We literally can't fix those. We could use WONTFIX but since humans read bugzilla it makes us just look uncooperative. I really think WONTFIX matches the EOL process better than CANTFIX anyway, because of the same connotations.

Okay. My main concern is that we chose something which we can dedicate specifically to this. I don't care very much about the particular name used. (INSUFFICIENT_DATA might also work, except that's also one that clearly makes sense as a normal resolution.)

As noted earlier, I'm also fine with leaving them in NEEDINFO state forever, although that might require maintainers to change their habits a little bit with regard to whether they treat those bugs as effectively open or out-of-sight-out-of-mind.

Replying to [comment:31 mattdm]:

Okay. My main concern is that we chose something which we can dedicate specifically to this. I don't care very much about the particular name used. (INSUFFICIENT_DATA might also work, except that's also one that clearly makes sense as a normal resolution.)

Yeah, the kernel team uses INSUFFICIENT_DATA a lot. Looking at the existing resolutions, DEFERRED is the only one that I think isn't used frequently but it also doesn't make sense either. If you're really bothered by it, it is probably better to request a new resolution that actually matches what you're trying to accomplish here. Something like EOL. Otherwise you run the risk of either stomping on existing maintainer workflow or having an unfriendly mapping that doesn't make sense.

As noted earlier, I'm also fine with leaving them in NEEDINFO state forever, although that might require maintainers to change their habits a little bit with regard to whether they treat those bugs as effectively open or out-of-sight-out-of-mind.

That would work. Then maintainers can close them as WONTFIX themselves if it bothers them.

So, will try and answer all the various stuff above. ;)

  • We can make an alias for bugzilla-ombudsman@fedoraproject.org, but perhaps this would be better as a list? Then anyone who wished could subscribe and help people out and you wouldn't be confused if someone replied without ccing the alias back, etc. I suspect it will also quickly however get a bunch of "My bug isn't fixed yet, please fix it" type emails, so in establishing such a thing you probibly want to define what the group does/does not do, etc. Additionally, should probibly ask QA folks about this.

  • We have no setup for survey's in infra. You would need to create/manage that externally. Again, it would be good to talk to others who are good at wording such things, as survey's skew quickly depending on how the questions are worded.

  • "could we change the NEEDINFO period from one month to the
    entire time until the next release is EOL". You mean when we set needinfo one month before EOL? I'm fine with that as long as when we close them, they stop appearing on maintainers radar/frontpage/whatever.

I'm a bit worried about making a bunch of changes right now before the process runs without announcing beforehand and getting feedback from maintainers and qa folks.

Replying to [comment:33 kevin]:

  • We can make an alias for bugzilla-ombudsman@fedoraproject.org, but perhaps this would be better as a list? Then anyone who wished could subscribe and help people out and you wouldn't be confused if someone replied without ccing the alias back, etc. I suspect it will also quickly however get a bunch of "My bug isn't fixed yet, please fix it" type emails, so in establishing such a thing you probibly want to define what the group does/does not do, etc. Additionally, should probibly ask QA folks about this.

A list is fine, although it would have to be open to posting from unsubscribed addresses.

Scoping the group and maybe coming up with some canned replies also seem like reasonable things to do, although that's getting a little more formal than I was hoping to. Maybe that's needed, though. In some cases, it may very well be that there is an unresponsive maintainer. If there's general interest in QA or more broadly in reviving something like bugzappers and/or making this into that, that'd be cool.

  • We have no setup for survey's in infra. You would need to create/manage that externally. Again, it would be good to talk to others who are good at wording such things, as survey's skew quickly depending on how the questions are worded.

Yeah I guess drop that idea for now, especially since others appear to like the alias/list idea.

  • "could we change the NEEDINFO period from one month to the
    entire time until the next release is EOL". You mean when we set needinfo one month before EOL? I'm fine with that as long as when we close them, they stop appearing on maintainers radar/frontpage/whatever.

    I'm a bit worried about making a bunch of changes right now before the process runs without announcing beforehand and getting feedback from maintainers and qa folks.

Yeah. I think the e-mail link provides some immediate improvement, and we can work on the rest over time.

From last FESCo meeting:

19:35:53 <mattdm> and I guess to punt on further possible changes until the next cycle (although presumably not so close to the end of it.)

To be clear on decision
* 1.
* a) do bugzilla ombudsman part now, even without any formal process and judge it case by case
* b) punt other ideas for the next cycle

Or
* 2. was it meant as punt all for now? As I felt some disagreement about ombudsman without formal process.

If 1., I'll ask for the list creation, would be nice to get some feedback from QA too (I'll ask today on Fedora QA meeting unless someone replies first ;-).

I was thinking 2 personally, but other fesco folks might feel differently.

I think the ombudsman setup could be nice, but we should make sure to have clear expectations what that group would do/cannot do to avoid hard feelings.

The EOL process for F18 is out now so this should just be punted which allows us move forwards with the future of triagers and assume this falls into that space if not we need to know which parts of the triagers process FESCO plans on owning...

Personal opinion (note on QA group opinion to follow): The new mailing list / alias approach sounds, to me, bizarre.

What is it for? What problem is it solving?

AFAICS we don't have a tooling problem here. Bugzilla provides all the tools we need. We can find all the bugs that will be EOLed, all the bugs that are being EOLed, all the bugs that have been EOLed. Anyone who has a problem with EOLing has a natural feedback channel: the bug itself! We can easily find any and all comments on EOL-related bugs.

Given this, how is a separate alias or mailing list a better feedback channel? What is it winning us? If the problem is that people just aren't interested in working to smooth this process, a shiny (or, really, not-so-shiny - more lists, ick) tool isn't going to help. If the problem is that we don't have a nice SOP or something explaining how to find EOL bug feedback and how to respond to it appropriate, we have a process problem, not a tooling problem. Write a process.

I agree that it's not necessarily a tools problem, but I also don't think we necessarily need a big fancy process. On the other hand, I think commenting in the bug isn't necessarily giving people the responsiveness that they maybe ought to have. The idea was just to give people a place to go when they feel like that isn't working, hopefully without increasing burden on maintainers directly.

As I said before, when I started doing this the first few times around, I added myself to the CC of every bug I closed and tried to deal with the responses personally. That doesn't exactly scale, and that's where the list/alias idea comes from.

If we want to make the thing this time around "just add mattdm and whoever else to the cc list as we're closing all of the bugs" + change the comment to "If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug", I guess that would be fine, and I + whoever else can set up a filter to catch such comments.

As for FESCo "owning" the process, I don't think that's the intention at all, except insomuch as FESCo is the steering committee overall.

I didn't mean a 'big fancy process'. If you want to make sure it's not big and fancy, just make sure you don't ask me to write it. ;)

The point is, if the problem is - as you suggest - that one person trying to respond to all the EOLed bugs doesn't scale, then all you need is a mechanism for having more than one person do it. It is not a difficult thing to ensure that all X people in an arbitrarily defined set will see the comments sent to a specific set of bugs (those bugs that have recently been EOLed). We're engineers, right? We can do that. One way or another. :)

For the record: this was discussed at the QA meeting this morning, and the following statement was agreed by those present:

"QA doesn't think any of the proposed improvements sounds great, and any change to the process should involve all stakeholders: we suggest FESCo punt on the question for now and consider viking-ice's triage revamp and post any future proposals to change the process to relevant groups' lists"

That sounds a bit mean, but basically we just all didn't quite think the current proposals hit anything right on the nose, and as we've already gone ahead and done the F20 EOL, there's no particular urgency to get the process changed RIGHT NOW IN A SCREAMING HURRY any more. So we can afford the time to come up with a well-reasoned proposal in a more widely-read setting (like, the relevant MLs) and get a broad consensus behind it.

Replying to [comment:40 mattdm]:

I agree that it's not necessarily a tools problem, but I also don't think we necessarily need a big fancy process. On the other hand, I think commenting in the bug isn't necessarily giving people the responsiveness that they maybe ought to have.

What they "ought to have" is their bugs fixed, and fixed in time. We aren't improving that...

The idea was just to give people a place to go when they feel like that isn't working, hopefully without increasing burden on maintainers directly.

... so what would the users get from spending yet more effort by going to that "place to go"?

(I'm open to an answer to the effect of "we are not technically serving them as they need but they will feel better about it for $reason", but AFAICS that's about the only thing we can actually do by changing the tooling/automation in this area, without actually having more contributed work on resolving the issues.)

Sorry for delay, the message based on mattdm comment is:

"Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed."

If approved, I'm going to adjust script and run it.

Replying to [comment:46 jreznik]:

"Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed."

Looks fine to me. +1

Yes, that looks fine. +1

Maybe I should open a separate issue, but why does the script do CLOSED->WONTFIX and file the comment as two separate bugzilla operations? It just doubles the quantity of mail that's sent out.

Replying to [comment:52 crobinso]:

Maybe I should open a separate issue, but why does the script do CLOSED->WONTFIX and file the comment as two separate bugzilla operations? It just doubles the quantity of mail that's sent out.

Two XML RPC calls are called (Bug.update, Bug.add_comment) and it's true both takes the same mail argument. I can change it to just send one email (looking on sources). I'm not sure if it's possible to make it one call, I'll check it (less burden for BZ, faster processing).

Bug.update takes a 'comment' field which will add a new comment, so one step should work. (FWIW I'm the python-bugzilla maintainer so I've dealt with the XMLRPC API quite a bit).

Replying to [comment:54 crobinso]:

Bug.update takes a 'comment' field which will add a new comment, so one step should work. (FWIW I'm the python-bugzilla maintainer so I've dealt with the XMLRPC API quite a bit).

Thanks Cole,
script has been adjusted to use one call only.

There's a discussion going on now on fedora-devel list about this -- subject "Auto-expiring bugs are getting absurd". https://lists.fedoraproject.org/pipermail/devel/2014-February/195257.html

For anyone interested in number of bugs closed EOL for last few releases: http://borntobeopen.blogspot.cz/2014/02/end-of-not-my-life.html

Okay, so, I checked with bugzilla people, and the proposal I posted to the Fedora Devel list https://lists.fedoraproject.org/pipermail/devel/2014-February/195293.html is doable. So I'm formally proposing it here:

Step one: when a release hits EOL, set the  Need Info flag, with
a notice similar to the current one. (Essentially moving the current
warning back a little bit.)

Step one point five: Pretty much anyone can clear the Need Info flag.

Step two: when the *next* release hits EOL (and the release under
consideration has been EOL for approximately 6 months), move any bugs
still with Need Info to a new closed resolution named CLOSED:EOL, with a
message similar to the current EOL note.

EOL wouldn't be visibile as an available status for bugzilla users to
select when closing a bug in the interface, so it does not add to UI
clutter, but also makes it easy for us to do reports distinguishing
between intentional and EOL closure. (This can be done by restricting
the transition to the already-existing Fedora EOL user account.)

This gives a much longer timeframe where we're waiting for input, so by
the time we actually close, the release has been EOL for a decent while
(rather than now, at the "I just got around to updating!" point).

It does risk some false positives (negatives? whatever) where Need Info
is cleared with "works for me" but the bug not closed, but that seems
a) a less serious problem and b) likely to be much smaller in number and
thus easier to triage manually if it becomes troublesome in itself.

I can change the script to use EOL resolution if it's doable in Bugzilla, limited only for end of life user.

For EOL bugs opened after the release hit end of life, I'm not sure about it as it could lead to false expectation we are going to fix bugs in EOLed release. So I'd like to have broader consensus on this change before it's going to be implemented in the script.

Replying to [comment:59 jreznik]:

For EOL bugs opened after the release hit end of life, I'm not sure about it as it could lead to false expectation we are going to fix bugs in EOLed release. So I'd like to have broader consensus on this change before it's going to be implemented in the script.

We can immediately make the version not open for new bugs when it hits EOL, can't we?

side note: version=18 is still available when filing new fedora bugs. possibly the SOP for EOL needs to be amended? should just be a request bugzilla admins to disable the old version.

Replying to [comment:61 crobinso]:

side note: version=18 is still available when filing new fedora bugs. possibly the SOP for EOL needs to be amended? should just be a request bugzilla admins to disable the old version.

I've fixed this for 18... but yes, it should get added to the SOP/process so it's not missed moving forward.

I'm fine with the proposed changes, except for the 'leave open after eol'. I think thats misleading and confusing to our users. I'd prefer all the changes proposed, but with closing at EOL time as we do now.

Replying to [comment:62 kevin]:

I'm fine with the proposed changes, except for the 'leave open after eol'. I think thats misleading and confusing to our users. I'd prefer all the changes proposed, but with closing at EOL time as we do now.

So, that's kind of fundamental. :) If we close at EOL, that's not really leaving much of a Need Info window. And making that window ''much'' longer is really the point.

I don't think it's really confusing -- the EOL message can be pretty clear.

Replying to [comment:61 crobinso]:

side note: version=18 is still available when filing new fedora bugs. possibly the SOP for EOL needs to be amended? should just be a request bugzilla admins to disable the old version.

It's in SOP, my fault - good catch.

So, at the FESCo meeting, there was some resistance to the idea of leaving EOL bugs in any sort of open state, even with NeedInfo. I checked with Simon Green (bugzilla maintainer) and he says that we can make it so anyone can reopen bugs from CLOSED:EOL, and we can make it so a change in version is required at that time.

I'm still primarily for my proposal above, but I would also be open to a new one involving this.

+1 to making it so anyone can open CLOSED EOL and force a version change at that time.

So, the new proposal is:

  1. New "CLOSED:EOL" resolution added.
  2. Only the EOL script will be able to put things into CLOSED:EOL
  3. Script will be run immediately when a release hits end of life. (Message needs to be adjusted.)
  4. Any user will be able to reopen bugs which are CLOSED:EOL, but without special privileges will be made to select a new, open Fedora version

And, questions:

a. Do we want to still do a pre-EOL warning? (I'd argue that it doesn't really add much but work and noise, as long as it's easy enough to reopen, which it will be.)
b. Do we want to do something towards automatically flagging particular bugs for further triage? I think we do, but that may be an entirely separate mini-project. (Possibly triggers include: high number of incoming duplicates, bugs with lots of comments, bugs with comments after the EOL message, bugs which have been closed at EOL and reopened in a previous cycle, bugs with multiple comments but none from the maintainer, and so on.)

FTR I am +1 to both the old and new proposals.

Replying to [comment:67 mattdm]:

So, the new proposal is:

  1. New "CLOSED:EOL" resolution added.
  2. Only the EOL script will be able to put things into CLOSED:EOL
  3. Script will be run immediately when a release hits end of life. (Message needs to be adjusted.)
  4. Any user will be able to reopen bugs which are CLOSED:EOL, but without special privileges will be made to select a new, open Fedora version
    OK.

a. Do we want to still do a pre-EOL warning?

I think we do. We ideally shouldn't have any users at the old release by EOL time; also, "we are moving development targets to a new release; help us with this and move with us" is a much better message than "we just closed your bug and you are behind the times".

b. Do we want to do something towards automatically flagging particular bugs for further triage?

We don't have anyone lining up to do more triage work, so who would use that?

I think we do, but that may be an entirely separate mini-project. (Possibly triggers include: high number of incoming duplicates, bugs with lots of comments,
... and even if we did want to add triage mechanisms - these would be the more interesting criteria, and are completely unrelated to EOL; let's not block the EOL decision on this.

Replying to [comment:69 mitr]:

b. Do we want to do something towards automatically flagging particular bugs for further triage?
We don't have anyone lining up to do more triage work, so who would use that?

I think this is kind of a "if we build it, they will come" thing. Right now, it's clearly an impossible task. With this, we could produce a report and, for example, award badges for dealing with bugs on it.

I agree that it shouldn't block what we are doing now.

I'm +1 to the 'new proposal'

On triage, there was some thought in QA about restarting a triage group/process. Details to be determined. We can/should adjust this process based on what folks want to do from that (ie, we should just approve the new proposal for now and revisit later IMHO).

Also, there is a good chance I hope we will get fedmsg from bugzilla in a few months. That will open up a lot of things.

a. Do we want to still do a pre-EOL warning?
I think we do. We ideally shouldn't have any users at the old release by EOL time; also, "we are moving development targets to a new release; help us with this and move with us" is a much better message than "we just closed your bug and you are behind the times".

For the record, sounds good. This should come at the release of the N+2 release, and should say something like what you say above. Do we want to allow any user to change the version at this point? (And, just at this point, or should we allow it always?)

Replying to [comment:67 mattdm]:

So, the new proposal is:

  1. New "CLOSED:EOL" resolution added.
  2. Only the EOL script will be able to put things into CLOSED:EOL
  3. Script will be run immediately when a release hits end of life. (Message needs to be adjusted.)
  4. Any user will be able to reopen bugs which are CLOSED:EOL, but without special privileges will be made to select a new, open Fedora version

+1 to this proposal.

And, questions:

a. Do we want to still do a pre-EOL warning? (I'd argue that it doesn't really add much but work and noise, as long as it's easy enough to reopen, which it will be.)

I don't see why it hurts, if it's simple enough to do.

b. Do we want to do something towards automatically flagging particular bugs for further triage? I think we do, but that may be an entirely separate mini-project. (Possibly triggers include: high number of incoming duplicates, bugs with lots of comments, bugs with comments after the EOL message, bugs which have been closed at EOL and reopened in a previous cycle, bugs with multiple comments but none from the maintainer, and so on.)

If someone wants to work on that, sure. But I think it's outside of the scope of this specific item.

  • AGREED: the new mattdm's proposal for EOL bug procedure is approved (+6, -0, 0:0) (t8m, 19:11:45)
  • ACTION: mattdm to coordinate with bugzilla maintainers to get the practical parts implemented (mattdm, 19:11:58)
  • AGREED: The pre-EOL warning still stays (with appropriate change of wording) (+7, -0, 0:0) (t8m, 19:14:08)

Thanks for working on this ticket, I'll make sure to adjust EOL script to contain requested changes. Matt, please ping me once you have answer from Bugzilla team.

Reopening this ticket to re-check before F19 EOL which is tomorrow.

  • We have the new EOL status but due to misunderstanding, status is CLOSED but resolution is CLOSED:EOL, see https://bugzilla.redhat.com/show_bug.cgi?id=1174396#c5 I already asked for the fix in related ticket.
  • "but without special privileges will be made to select a new, open Fedora version" requires coding on BZ side. If we disable 19 as version, will BZ automatically enforce newer version?
  • For the pre-EOL warning, unfortunately it's my mistake, I remembered "no pre-EOL" warning. So exactly opposite way... And no pre-EOL was sent...

Do we want to wait to finish changes and send pre-EOL warning meanwhile (but shorter aka one/two weeks)? Or proceed (usually I run the script day, two days after last push, so Bodhi has time to update resolutions). On the other hand, F19 is already quite long.

Btw for EOL warning - it's not that much work, to answer question raised in the ticket but it's a script updating several thousand of bugs. It takes a few days to finish and it means some load on already slow Bugzilla. For spam - yes, some maintainers complains it sends a huge amount of emails (for some). I can't say what's the reasonable number of updates in the period between warning and EOL. Some bugs are updated but the number is pretty low from my observation (compared to total number of bugs touched).

Fedora 19 EOL message:

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

F19 EOL warning will be sent today. We will auto-close all remaining bugs in one month. (sgallagh, 19:28:14)

Login to comment on this ticket.

Metadata