Re: proposal for changes to auto-expiring bugs
On Thu, Feb 06, 2014 at 07:30:44AM -0500, Jaroslav Reznik wrote: I'm not sure adding a new EOL status would be ok for Bugzilla guys, as far as I know, there were some efforts to cut down BZ statuses (ON_DEV for I checked with bugzilla people, and Simon Green says that making a EOL resolution would be no problem, and that it could be restricted to the EOL user. So I'm going to take this back to https://fedorahosted.org/fesco/ticket/1198 -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
proposal for changes to auto-expiring bugs
On Wed, Feb 05, 2014 at 02:50:59PM -0800, Adam Williamson wrote: The problem is that no-one seems to come up with an alternative that's any better. Leaving bugs on EOL versions open to rot away and be ignored is no use. We *could* give everyone privs to re-open closed bugs, I guess, and I personally don't think that would end terribly, but it's kind of a radical plan. I would like to see one of the following, in order of preference: 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with a notice similar to the current one. (Essentially moving the current warning back a little bit.) Step one point five: I believe pretty much anyone can clear the NEEDINFO 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 in NEEDINFO to a new closed resolution like 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 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). This does risk some false positives (negatives? whatever) where NEEDINFO is cleared with works for me but the bug not closed, but that seems like a less serious problem. 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or and add a ClosedEOL keyword automatically. This is uglier than the above but requires no bugzilla change. 3. As #1, but just leave bugs in NEEDINFO state forever. This would possibly require maintainers to update their searches / filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older releases. Any of these seem pretty easy and I think would improve the situation for users and bug reporters without badly increasing maintainer burden or being dishonest about our ability to fix all the things. Additionally, but requiring some development, we could add some heuristics like: don't autoclose bugs with many incoming duplicate pointers, or possibly (as David suggests) bugs with comments, or bugs which have been reopened, or (here I get handwavy). -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
- Original Message - On Wed, Feb 05, 2014 at 02:50:59PM -0800, Adam Williamson wrote: The problem is that no-one seems to come up with an alternative that's any better. Leaving bugs on EOL versions open to rot away and be ignored is no use. We *could* give everyone privs to re-open closed bugs, I guess, and I personally don't think that would end terribly, but it's kind of a radical plan. I would like to see one of the following, in order of preference: 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with a notice similar to the current one. (Essentially moving the current warning back a little bit.) Step one point five: I believe pretty much anyone can clear the NEEDINFO 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 in NEEDINFO to a new closed resolution like 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 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). This does risk some false positives (negatives? whatever) where NEEDINFO is cleared with works for me but the bug not closed, but that seems like a less serious problem. 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or and add a ClosedEOL keyword automatically. This is uglier than the above but requires no bugzilla change. I'm not sure adding a new EOL status would be ok for Bugzilla guys, as far as I know, there were some efforts to cut down BZ statuses (ON_DEV for example), even it would be hidden. So keyword looks like much more easier solution. Jaroslav 3. As #1, but just leave bugs in NEEDINFO state forever. This would possibly require maintainers to update their searches / filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older releases. Any of these seem pretty easy and I think would improve the situation for users and bug reporters without badly increasing maintainer burden or being dishonest about our ability to fix all the things. Additionally, but requiring some development, we could add some heuristics like: don't autoclose bugs with many incoming duplicate pointers, or possibly (as David suggests) bugs with comments, or bugs which have been reopened, or (here I get handwavy). -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, Feb 06, 2014 at 07:30:44AM -0500, Jaroslav Reznik wrote: 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or and add a ClosedEOL keyword automatically. This is uglier than the above but requires no bugzilla change. I'm not sure adding a new EOL status would be ok for Bugzilla guys, as far as I know, there were some efforts to cut down BZ statuses (ON_DEV for example), even it would be hidden. So keyword looks like much more easier solution. I think it depends on the reasons for cutting down on statuses (or in this case, resolutions). If it's for performance reasons or some other practical concern, okay. But if it's because the plethora of options is confusing to users, I think hiding it from the UI should be okay. We could ask. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, 2014-02-06 at 04:00 -0500, Matthew Miller wrote: Additionally, but requiring some development, we could add some heuristics like: don't autoclose bugs with many incoming duplicate pointers, or possibly (as David suggests) bugs with comments, or bugs which have been reopened, or (here I get handwavy). Your whole proposal more or less *is* the heuristic 'don't autoclose bugs with comments', because of how needinfo works in RH bugzilla. It's not a status (as you imply by writing NEEDINFO) but a flag. If you set the needinfo flag not against a specific person but against 'anyone', then by default, the next person who posts a comment of any kind will clear the flag - they have to uncheck a little box if they want to *not* clear the flag. I still don't actually think it's a bad proposal, just wanted to be sure the implications of using the needinfo flag were clear :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, 6 Feb 2014 04:00:17 -0500 Matthew Miller mat...@fedoraproject.org wrote: I would like to see one of the following, in order of preference: 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with a notice similar to the current one. (Essentially moving the current warning back a little bit.) Step one point five: I believe pretty much anyone can clear the NEEDINFO 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 in NEEDINFO to a new closed resolution like CLOSED:EOL, with a message similar to the current EOL note. So, all those bugs stay open on the EOL version until EOL+1? That seems poor to me. What do we do if someone clears needinfo and says: Yes, this still affects me, I am running EOL release. Please fix it. We cannot, the EOL release is closed, no more updates or support. How does leaving it open there help? 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. Is this possible? 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). This does risk some false positives (negatives? whatever) where NEEDINFO is cleared with works for me but the bug not closed, but that seems like a less serious problem. Yeah, thats another issue with this... they would stick around in that case until the maintainer or someone came in and cleared them. 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or and add a ClosedEOL keyword automatically. This is uglier than the above but requires no bugzilla change. 3. As #1, but just leave bugs in NEEDINFO state forever. This would possibly require maintainers to update their searches / filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older releases. It would also be misleading, IMHO. Hey reporter, I need info to fix this Here you go, here's the info you wanted from my Fedora 7 machine, please provide update kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Feb 6, 2014 11:06 AM, Kevin Fenzi ke...@scrye.com wrote: On Thu, 6 Feb 2014 04:00:17 -0500 Matthew Miller mat...@fedoraproject.org wrote: I would like to see one of the following, in order of preference: 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with a notice similar to the current one. (Essentially moving the current warning back a little bit.) Step one point five: I believe pretty much anyone can clear the NEEDINFO 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 in NEEDINFO to a new closed resolution like CLOSED:EOL, with a message similar to the current EOL note. So, all those bugs stay open on the EOL version until EOL+1? That seems poor to me. What do we do if someone clears needinfo and says: Yes, this still affects me, I am running EOL release. Please fix it. We cannot, the EOL release is closed, no more updates or support. How does leaving it open there help? 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. Is this possible? 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). This does risk some false positives (negatives? whatever) where NEEDINFO is cleared with works for me but the bug not closed, but that seems like a less serious problem. Yeah, thats another issue with this... they would stick around in that case until the maintainer or someone came in and cleared them. 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or and add a ClosedEOL keyword automatically. This is uglier than the above but requires no bugzilla change. 3. As #1, but just leave bugs in NEEDINFO state forever. This would possibly require maintainers to update their searches / filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older releases. It would also be misleading, IMHO. Hey reporter, I need info to fix this Here you go, here's the info you wanted from my Fedora 7 machine, please provide update kevin -- What do you all think about adding a note to bugs against Fedora N-1 when Fedora N is released, ie: You filed this bug against Fedora 19, and Fedora 20 has recently been released. A new Fedora release includes a version update for many packages, and your issue may have been resolved. Please consider checking to see if your issue persists in Fedora 20 and updating this ticket accordingly. Any bugs remaining open when support ends for Fedora 19, shortly after the release of Fedora 21, unless the issue affects Fedora 20 or Fedora 21. Not polished copy, obviously, but giving the reporter some more warning/prodding can't hurt. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, Feb 06, 2014 at 09:49:26AM -0800, Adam Williamson wrote: Your whole proposal more or less *is* the heuristic 'don't autoclose bugs with comments', because of how needinfo works in RH bugzilla. It's not a status (as you imply by writing NEEDINFO) but a flag. If you set the needinfo flag not against a specific person but against 'anyone', then by default, the next person who posts a comment of any kind will clear the flag - they have to uncheck a little box if they want to *not* clear the flag. Thanks, yes. Once upon a time in the decent past (like, embarrassingly long ago) it *was* a status, and apparently way too much of that is still in my brain. I went back and reread what I wrote, and I think it still makes sense with your clarification. The above was certainly exactly why I propose this -- it's not just moving around what we happen to call things, but has an actual positive change to the user experience. It is the case that it being a flag rather than a status makes it a bit more complicated to set up searches for bugs which are open but don't have the flag set. But it's still doable, so I hope that doesn't undermine it too much. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, Feb 06, 2014 at 11:06:07AM -0700, Kevin Fenzi wrote: So, all those bugs stay open on the EOL version until EOL+1? That seems poor to me. What do we do if someone clears needinfo and says: Yes, this still affects me, I am running EOL release. Please fix it. We cannot, the EOL release is closed, no more updates or support. How does leaving it open there help? It doesn't, but I think the trouble of closing those by hand is overall less than the problem of closing too many bugs 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. Is this possible? I believe so -- you only make the transition available to the Fedora EOL user account. But because it's bugzilla, this kind of thing may involve writing some Perl, and I'm sympathetic to the bugzilla maintenance team not wanting to deal with that. (That's the main reason for suggesting the second option, of setting a keyword instead.) This does risk some false positives (negatives? whatever) where NEEDINFO is cleared with works for me but the bug not closed, but that seems like a less serious problem. Yeah, thats another issue with this... they would stick around in that case until the maintainer or someone came in and cleared them. Yes, but see the other message. At the very least, I bet it will be dozens or at worst hundreds, which is a managable amount for people interested in helping with EOL triage. On the other side, we have many thousands of auto-closed bugs right now. And I think that triage work would really only be needed if we end up feeling that we've tilted the balance too far in the direction of making the package maintainers clean up. 3. As #1, but just leave bugs in NEEDINFO state forever. This would possibly require maintainers to update their searches / filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older releases. It would also be misleading, IMHO. Hey reporter, I need info to fix this In this case, the message would be something like We're sorry we weren't able to resolve this bug within the lifespan of Fedora ##. We do appreciate the report, and we may be able to fix it in the next release. Could you please confirm that this is still an issue in the latest release of Fedora? Thank you. With this message, if needinfo is cleared, and then the bug isn't touched for a long time, it would probably be a good candidate for human triage. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
