Ticket #1198 (closed task: fixed)

Opened 22 months ago

Last modified 8 months ago

Possible changes to Fedora EOL bug procedure

Reported by: mattdm Owned by:
Priority: major Keywords: meeting
Cc: jreznik@…, crobinso@… Blocked By:
Blocking:

Description

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 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.

Change History

comment:1 in reply to: ↑ description Changed 22 months ago by jreznik

Replying to 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 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.

comment:2 Changed 22 months ago by kevin

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

comment:3 Changed 22 months ago by kkofler

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.

comment:4 follow-up: ↓ 5 Changed 22 months ago by 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? Then that's a clearcut bug in our Bugzilla setup and needs to be fixed there.

comment:5 in reply to: ↑ 4 Changed 22 months ago by mattdm

Replying to 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.)

comment:6 Changed 22 months ago by jreznik

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

comment:7 Changed 22 months ago by toshio

+1 to making that change in bugzilla then.

comment:8 Changed 22 months ago by sgallagh

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

comment:9 Changed 21 months ago by jreznik

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...

comment:10 Changed 21 months ago by mattdm

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.)

comment:11 Changed 21 months ago by mmaslano

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

comment:12 Changed 21 months ago by mattdm

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

comment:13 follow-up: ↓ 16 Changed 21 months ago by 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.

comment:14 Changed 21 months ago by toshio

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

comment:15 follow-up: ↓ 17 Changed 21 months ago by mattdm

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.

comment:16 in reply to: ↑ 13 Changed 21 months ago by jreznik

Replying to 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.

comment:17 in reply to: ↑ 15 Changed 21 months ago by jreznik

Replying to 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.

comment:18 Changed 21 months ago by jreznik

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

comment:19 Changed 21 months ago by mattdm

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

comment:20 Changed 21 months ago by mmaslano

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

comment:21 Changed 21 months ago by toshio

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.

comment:22 Changed 20 months ago by jreznik

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

comment:23 Changed 20 months ago by tmraz

  • Keywords meeting removed

comment:24 Changed 20 months ago by adamwill

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.

comment:25 Changed 20 months ago by jreznik

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.

comment:26 follow-up: ↓ 28 Changed 20 months ago by 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@…." With that alias then forwarding to one or more people willing to help.
  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.

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).

comment:27 Changed 20 months ago by mattdm

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?

comment:28 in reply to: ↑ 26 Changed 20 months ago by jreznik

Replying to 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@…." 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.

comment:29 follow-up: ↓ 30 Changed 20 months ago by 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.

comment:30 in reply to: ↑ 29 Changed 20 months ago by jwboyer

Replying to 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.

comment:31 follow-up: ↓ 32 Changed 20 months ago by 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.)

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.

comment:32 in reply to: ↑ 31 Changed 20 months ago by jwboyer

Replying to 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.

comment:33 follow-up: ↓ 34 Changed 20 months ago by kevin

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

  • We can make an alias for bugzilla-ombudsman@…, 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.

comment:34 in reply to: ↑ 33 Changed 20 months ago by mattdm

Replying to kevin:

  • We can make an alias for bugzilla-ombudsman@…, 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.

comment:35 Changed 20 months ago by mmaslano

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.)

comment:36 Changed 20 months ago by jreznik

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 ;-).

comment:37 Changed 20 months ago by kevin

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.

comment:38 Changed 20 months ago by johannbg

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...

comment:39 Changed 20 months ago by adamwill

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.

comment:40 follow-up: ↓ 44 Changed 20 months ago by 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. 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.

comment:41 Changed 20 months ago by adamwill

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. :)

Last edited 20 months ago by adamwill (previous) (diff)

comment:42 Changed 20 months ago by adamwill

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.

comment:44 in reply to: ↑ 40 Changed 20 months ago by mitr

Replying to 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.)

Last edited 20 months ago by mitr (previous) (diff)

comment:45 Changed 19 months ago by crobinso

  • Cc crobinso@… added

comment:46 follow-up: ↓ 47 Changed 19 months ago by jreznik

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.

comment:47 in reply to: ↑ 46 Changed 19 months ago by sgallagh

Replying to 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

comment:48 Changed 19 months ago by tmraz

Yes, that looks fine. +1

comment:49 Changed 19 months ago by mmaslano

+1

comment:50 Changed 19 months ago by kevin

+1 here.

comment:51 Changed 19 months ago by notting

+1

comment:52 follow-up: ↓ 53 Changed 19 months ago by 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.

comment:53 in reply to: ↑ 52 Changed 19 months ago by jreznik

Replying to 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).

comment:54 follow-up: ↓ 55 Changed 19 months ago by 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).

comment:55 in reply to: ↑ 54 Changed 19 months ago by jreznik

Replying to 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.

comment:56 Changed 19 months ago by mattdm

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

comment:57 Changed 19 months ago by jreznik

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

comment:58 Changed 19 months ago by mattdm

  • Keywords meeting added

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.

comment:59 follow-up: ↓ 60 Changed 19 months ago by jreznik

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.

comment:60 in reply to: ↑ 59 Changed 19 months ago by mattdm

Replying to 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?

comment:61 follow-ups: ↓ 62 ↓ 64 Changed 19 months ago by 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.

comment:62 in reply to: ↑ 61 ; follow-up: ↓ 63 Changed 19 months ago by kevin

Replying to 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.

comment:63 in reply to: ↑ 62 Changed 19 months ago by mattdm

Replying to 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.

comment:64 in reply to: ↑ 61 Changed 19 months ago by jreznik

Replying to 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.

comment:65 Changed 19 months ago by mattdm

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.

comment:66 Changed 19 months ago by toshio

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

comment:67 follow-ups: ↓ 69 ↓ 73 Changed 19 months ago by 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

And, questions:

  1. 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.)
  2. 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.)

comment:68 Changed 19 months ago by mattdm

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

comment:69 in reply to: ↑ 67 ; follow-ups: ↓ 70 ↓ 72 Changed 19 months ago by mitr

Replying to 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.

  1. 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".

  1. 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.

comment:70 in reply to: ↑ 69 Changed 19 months ago by mattdm

Replying to mitr:

  1. 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.

comment:71 Changed 19 months ago by kevin

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.

comment:72 in reply to: ↑ 69 Changed 19 months ago by mattdm

  1. 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?)

comment:73 in reply to: ↑ 67 Changed 19 months ago by notting

Replying to 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:

  1. 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.

  1. 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.

comment:74 Changed 19 months ago by tmraz

  • Resolution set to fixed
  • Status changed from new to closed
  • 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)

comment:75 Changed 19 months ago by jreznik

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.

comment:76 Changed 8 months ago by jreznik

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:77 Changed 8 months ago by jreznik

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.

comment:78 Changed 8 months ago by sgallagh

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

comment:79 Changed 8 months ago by sgallagh

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.