Re: Marking zapped bugs
On Sat, 2011-09-03 at 10:45 +0200, Matej Cepl wrote: Dne 2.9.2011 22:54, Adam Williamson napsal(a): Hum, I didn't realize our resolutions were so customized, I thought they were the upstream ones; this is what I've been told when discussing custom resolutions in the past. It's certainly something you could propose as an enhancement by filing a bug against Bugzilla, then. If we had upstream’s UNCONFIRMED we wouldn't have to play with the Triaged keyword (although the meaning is subtly different). More than subtly. We explicitly *don't* require triagers to confirm bugs on their own systems. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
Dne 2.9.2011 22:54, Adam Williamson napsal(a): Hum, I didn't realize our resolutions were so customized, I thought they were the upstream ones; this is what I've been told when discussing custom resolutions in the past. It's certainly something you could propose as an enhancement by filing a bug against Bugzilla, then. If we had upstream’s UNCONFIRMED we wouldn't have to play with the Triaged keyword (although the meaning is subtly different). Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
Dne 3.9.2011 00:33, Matt McCutchen napsal(a): bugs would harmonize with the current RHEL policy. None of my 131 bugs have been marked CANTFIX [2]; maintainers seem to find that the better-known WONTFIX and NOTABUG cover the range of cases. I use it routinely as a polite version of WONTFIX for Xorg bugs with nvidia binary driver. But yes, that's not a big deal. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
[Finally returning to this issue. If your mail client doesn't thread across this time span, see https://lists.fedoraproject.org/pipermail/devel/2010-November/145105.html for the previous part of the thread.] On Fri, 2010-11-05 at 12:19 -0700, Adam Williamson wrote: On Thu, 2010-11-04 at 16:10 -0400, Matt McCutchen wrote: On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, That's, um, exactly the process we're discussing here. We close all bugs for a given release when that release goes EOL. (I forget what resolution is used, it may well be WONTFIX). The resolution is indeed WONTFIX. We send a warning note to all bugs that will be closed under this process, a short while before they're closed, so the reporters can check if they exist in a newer version and bump the report to that version to keep it open, if they like. I'm well aware of the process. The principle behind it is that maintainers are not expected to act on bugs that have not been reproduced in a currently maintained version of Fedora, and such bugs should be marked so that users know not to expect any action. I am not disputing this. However, the generally accepted definition of WONTFIX is that the bug has at least some validity but the maintainer has decided not to address it because the benefit fails to outweigh the cost (implementation and maintenance effort + any negative side effects, to include going outside the intended scope of the software). Zapping bugs by marking them WONTFIX is semantically incorrect and makes then hard to distinguish from bugs that meet the accepted definition of WONTFIX; it has also seemed on some occasions to lead maintainers to abuse NOTABUG to mean WONTFIX. Fedora is the only project I am aware of that does this. I urge that bug zapping should be accomplished: (1) With a different resolution, like Mozilla's EXPIRED (I can file the bug against Red Hat Bugzilla), or (2) Without mutating bugs in any way, but by publicizing that non-FutureFeature bugs open against EOL Fedora versions are considered expired and no action should be expected (GNOME seems to operate this way informally). Optionally, Bugzilla could be customized to return the resolution of such bugs as EXPIRED to facilitate the exclusion of expired bugs from counts/queries of open bugs as desired. If we don't auto-close bugs we wind up with a huge pile of ancient bugs which just gets in the way of people who want to come along and actually clean up the bug list for a package. It's harder to do that if you're looking at reports from the Stone Age. What you're really saying is that most maintainers want to work from a list of unexpired bugs. But there are ways to achieve that other than marking all the expired bugs WONTFIX. Maintainers can always filter on the currently maintained Fedora versions, but it becomes tedious to configure that, which is where a virtual EXPIRED resolution exposed by Bugzilla would come in handy. My broader point is that calling expired bugs closed is an oversimplification, and possibly a disingenuously generous interpretation of the situation. I'd guess that among non-ABRT bugs, well over 50% of expired bugs are still valid two Fedora versions later. But regardless of the figure, I believe that each client querying Bugzilla should be allowed to decide whether or not to include expired bugs, as distinguished from true closed bugs, based on its own needs. By stuffing expired bugs into the WONTFIX category, Fedora is depriving them of that choice. [I am not on the list; please keep me in replies.] -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Fri, 2011-09-02 at 14:01 -0400, Matt McCutchen wrote: What you're really saying is that most maintainers want to work from a list of unexpired bugs. But there are ways to achieve that other than marking all the expired bugs WONTFIX. Maintainers can always filter on the currently maintained Fedora versions, but it becomes tedious to configure that, which is where a virtual EXPIRED resolution exposed by Bugzilla would come in handy. Mostly your proposal makes sense, but we're trying very hard to stick to upstream Bugzilla since 3.x, as heavy customization of 2.x caused more problems than it solved. So we're reluctant to add resolutions and statuses that don't exist upstream - even if Mozilla have hacked up their own copy of their own upstream bug reporting system to add resolutions... (if EXPIRED really exists in upstream bugzilla, that'd be a different case.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Fri, 2011-09-02 at 12:29 -0700, Adam Williamson wrote: On Fri, 2011-09-02 at 14:01 -0400, Matt McCutchen wrote: What you're really saying is that most maintainers want to work from a list of unexpired bugs. But there are ways to achieve that other than marking all the expired bugs WONTFIX. Maintainers can always filter on the currently maintained Fedora versions, but it becomes tedious to configure that, which is where a virtual EXPIRED resolution exposed by Bugzilla would come in handy. Mostly your proposal makes sense, Thanks for the response. but we're trying very hard to stick to upstream Bugzilla since 3.x, as heavy customization of 2.x caused more problems than it solved. So we're reluctant to add resolutions and statuses that don't exist upstream - even if Mozilla have hacked up their own copy of their own upstream bug reporting system to add resolutions... I don't buy that: Red Hat Bugzilla currently has 4 upstream resolutions to 7 custom ones. Are all the custom resolutions actively being phased out? Otherwise, can you give some examples to illustrate the marginal harm likely to occur if an 8th custom resolution is added? I'm disappointed that you don't appear to buy that this is important enough to merit discussion of alternatives, rather than just raising a problem with one of the ones I mentioned. The status quo may be fine for a maintainer or triager going down a work list, but when I as a user review old bugs related to a topic (perhaps to see whether a new bug is merited or I should join an old one), expired is equivalent to NEW rather than WONTFIX as far as I'm concerned, and it's annoying to have to open each WONTFIX bug to determine which kind it is. We have a number of options here which vary in implementation effort and how much burden they impose on user and/or maintainer to get what they want from an inadequate representation: 1. Status quo: hard to distinguish expired from WONTFIX. 2a. Add EXPIRED resolution and use it. 2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX (semantically questionable on its face, but maybe reasonable in light of the explanation on https://bugzilla.redhat.com/page.cgi?id=fields.html#status ). 3. Do not change the bug state, and have maintainers apply the same conditions now used by the bug zapper on all of their searches. Reducing mutable state is generally good in that it reduces the possible ways for things to get out of whack. But then it takes more work to see whether a non-CLOSED bug is expired. 3a. Like #3, but make it easier with a virtual EXPIRED resolution. Probably an undesirable level of customization to Bugzilla. 4. Add an Expired keyword or custom field, use it, and: 4a. Continue to close the bugs WONTFIX. Ugh, but I can use the keyword/field in search and maybe even get it to show as a column on search results. 4b. Do not change the status, and have maintainers use the keyword/field in their search. No one should object to 4a as a change (though I recognize I am still asking someone to do work, especially if existing bugs are to be reclassified). We could start with that and at least stop losing the data in the next bug zapping cycle. I would appreciate your honest consideration (Adam and any other relevant parties). -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
Matt McCutchen (m...@mattmccutchen.net) said: We have a number of options here which vary in implementation effort and how much burden they impose on user and/or maintainer to get what they want from an inadequate representation: 1. Status quo: hard to distinguish expired from WONTFIX. 2a. Add EXPIRED resolution and use it. 2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX (semantically questionable on its face, but maybe reasonable in light of the explanation on https://bugzilla.redhat.com/page.cgi?id=fields.html#status ). This (using CANTFIX instead of WONTFIX) seems like the simplest one to me. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Fri, 2011-09-02 at 16:43 -0400, Matt McCutchen wrote: On Fri, 2011-09-02 at 12:29 -0700, Adam Williamson wrote: On Fri, 2011-09-02 at 14:01 -0400, Matt McCutchen wrote: What you're really saying is that most maintainers want to work from a list of unexpired bugs. But there are ways to achieve that other than marking all the expired bugs WONTFIX. Maintainers can always filter on the currently maintained Fedora versions, but it becomes tedious to configure that, which is where a virtual EXPIRED resolution exposed by Bugzilla would come in handy. Mostly your proposal makes sense, Thanks for the response. but we're trying very hard to stick to upstream Bugzilla since 3.x, as heavy customization of 2.x caused more problems than it solved. So we're reluctant to add resolutions and statuses that don't exist upstream - even if Mozilla have hacked up their own copy of their own upstream bug reporting system to add resolutions... I don't buy that: Red Hat Bugzilla currently has 4 upstream resolutions to 7 custom ones. Are all the custom resolutions actively being phased out? Otherwise, can you give some examples to illustrate the marginal harm likely to occur if an 8th custom resolution is added? Hum, I didn't realize our resolutions were so customized, I thought they were the upstream ones; this is what I've been told when discussing custom resolutions in the past. It's certainly something you could propose as an enhancement by filing a bug against Bugzilla, then. 2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX (semantically questionable on its face, but maybe reasonable in light of the explanation on https://bugzilla.redhat.com/page.cgi?id=fields.html#status ). As noted at the top of that page, that is the policy for RHEL, not for Fedora. Fedora policy is https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED . It states only The resolutions CANTFIX, WONTFIX, and WORKSFORME are for use by maintainers only, and are self-explanatory. 3. Do not change the bug state, and have maintainers apply the same conditions now used by the bug zapper on all of their searches. Reducing mutable state is generally good in that it reduces the possible ways for things to get out of whack. But then it takes more work to see whether a non-CLOSED bug is expired. 3a. Like #3, but make it easier with a virtual EXPIRED resolution. Probably an undesirable level of customization to Bugzilla. 4. Add an Expired keyword or custom field, use it, and: 4a. Continue to close the bugs WONTFIX. Ugh, but I can use the keyword/field in search and maybe even get it to show as a column on search results. 4b. Do not change the status, and have maintainers use the keyword/field in their search. I think if we're going to change this, the only sensible change is to use a different CLOSED resolution. All the others seem like hacks which are likely to cause more trouble/confusion than they resolve. We clearly want to bugs to be CLOSED, not open with a quasi-closed keyword or whiteboard field. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Fri, 2011-09-02 at 13:54 -0700, Adam Williamson wrote: Hum, I didn't realize our resolutions were so customized, I thought they were the upstream ones; this is what I've been told when discussing custom resolutions in the past. It's certainly something you could propose as an enhancement by filing a bug against Bugzilla, then. OK, I will do that and post the link here. Any assessment of difficulty provided by the Bugzilla team can inform a decision between 2a and 2b. 2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX (semantically questionable on its face, but maybe reasonable in light of the explanation on https://bugzilla.redhat.com/page.cgi?id=fields.html#status ). As noted at the top of that page, that is the policy for RHEL, not for Fedora. Fedora policy is https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED . It states only The resolutions CANTFIX, WONTFIX, and WORKSFORME are for use by maintainers only, and are self-explanatory. You are right. But taking a step back, the project has the power to change the policy to best meet its needs. My point stands that the resolution is little-used (less than 2% [1]), and its use for expired bugs would harmonize with the current RHEL policy. None of my 131 bugs have been marked CANTFIX [2]; maintainers seem to find that the better-known WONTFIX and NOTABUG cover the range of cases. [1] https://bugzilla.redhat.com/report.cgi?x_axis_field=versiony_axis_field=resolutionquery_format=report-tableproduct=Fedoraformat=tableaction=wrap) [2] https://bugzilla.redhat.com/report.cgi?x_axis_field=versiony_axis_field=resolutionquery_format=report-tableproduct=Fedoraemailreporter1=1emailtype1=exactemail1=matt%40mattmccutchen.netformat=tableaction=wrap 3. Do not change the bug state, and have maintainers apply the same conditions now used by the bug zapper on all of their searches. Reducing mutable state is generally good in that it reduces the possible ways for things to get out of whack. But then it takes more work to see whether a non-CLOSED bug is expired. 3a. Like #3, but make it easier with a virtual EXPIRED resolution. Probably an undesirable level of customization to Bugzilla. 4. Add an Expired keyword or custom field, use it, and: 4a. Continue to close the bugs WONTFIX. Ugh, but I can use the keyword/field in search and maybe even get it to show as a column on search results. 4b. Do not change the status, and have maintainers use the keyword/field in their search. I think if we're going to change this, the only sensible change is to use a different CLOSED resolution. All the others seem like hacks which are likely to cause more trouble/confusion than they resolve. Fair assessment. We clearly want to bugs to be CLOSED, not open with a quasi-closed keyword or whiteboard field. I'm not sure who we is, but I disagree. The generally accepted definition of CLOSED is that the resolution is final unless subsequent events invalidate the original rationale. (C.f. the RHEL policy: The bug is considered dead, the resolution is correct.) All it takes for an expired bug to be reopened is for someone to have enough interest to retest it in a maintained Fedora version. To claim that this meets the definition of CLOSED is a big stretch. I believe that expired should properly be its own major state alongside open and closed, but we have alternatives that are less radical and still solve the immediate problem with search. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Fri, 2011-09-02 at 18:33 -0400, Matt McCutchen wrote: We clearly want to bugs to be CLOSED, not open with a quasi-closed keyword or whiteboard field. I'm not sure who we is, but I disagree. The generally accepted definition of CLOSED is that the resolution is final unless subsequent events invalidate the original rationale. (C.f. the RHEL policy: The bug is considered dead, the resolution is correct.) All it takes for an expired bug to be reopened is for someone to have enough interest to retest it in a maintained Fedora version. To claim that this meets the definition of CLOSED is a big stretch. I believe that expired should properly be its own major state alongside open and closed, but we have alternatives that are less radical and still solve the immediate problem with search. The reason for the auto-closing is 'problems with search': developers do not want to have searches for open bugs cluttered up with bugs for ancient versions. Any change which involves not closing the old bugs will result in the auto-close procedure not solving this problem any more, because the bugs will show up in a default search, and - as you mentioned - developers will have to remember to customize their searches every time to cover only currently-active versions. If we were to do that we might as well not do anything to old bugs automatically at all, because it's about as easy to customize a search to 'fedora 14, fedora 15, fedora 16, rawhide' as it is to customize it to 'no bugs with keyword EXPIRED'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
* Adam Williamson [03/09/2011 00:21] : Hum, I didn't realize our resolutions were so customized, I thought they were the upstream ones; this is what I've been told when discussing custom resolutions in the past. It's certainly something you could propose as an enhancement by filing a bug against Bugzilla, then. Custom resolutions these days fall in the configration scope. There is no hacking of code required. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Fri, 2011-09-02 at 15:43 -0700, Adam Williamson wrote: On Fri, 2011-09-02 at 18:33 -0400, Matt McCutchen wrote: We clearly want to bugs to be CLOSED, not open with a quasi-closed keyword or whiteboard field. I'm not sure who we is, but I disagree. The generally accepted definition of CLOSED is that the resolution is final unless subsequent events invalidate the original rationale. (C.f. the RHEL policy: The bug is considered dead, the resolution is correct.) All it takes for an expired bug to be reopened is for someone to have enough interest to retest it in a maintained Fedora version. To claim that this meets the definition of CLOSED is a big stretch. I believe that expired should properly be its own major state alongside open and closed, but we have alternatives that are less radical and still solve the immediate problem with search. The reason for the auto-closing is 'problems with search': developers do not want to have searches for open bugs cluttered up with bugs for ancient versions. Yes, of course. I was only responding to your apparent claim (at the top) that the use of CLOSED is semantically desirable. Any change which involves not closing the old bugs will result in the auto-close procedure not solving this problem any more, because the bugs will show up in a default search, and - as you mentioned - developers will have to remember to customize their searches every time to cover only currently-active versions. You are assuming that developers start from the default search to bring up their work lists. Do they? There are alternatives: - We can set up a shortened URL for a Fedora developer default search that pre-fills the appropriate fields on the query form, e.g., https://bugzilla.redhat.com/query.cgi?classification=Fedoraproduct=Fedoraversion=14version=15version=16version=rawhide . This would also save the Refresh Components latency. - They could use a saved query, which would change either every 6 months or not at all. - They could use http://bugz.fedoraproject.org/%s, which can be changed to do whatever they generally want. If we insist that the default search exclude expired bugs, it is already customized (compare https://bugzilla.redhat.com/query.cgi to https://landfill.bugzilla.org/bugzilla-tip/query.cgi?format=advanced), so we may be able to make a further customization to exclude expired Fedora bugs without affecting other products. But IMO, the default search should target the most common use case, which may well be users if developers do most of their queries a different way. My intent in putting forth this argument is to get past preconceptions and accurately assess the real drawbacks of approaches that do not close the bugs, since they are slightly better semantically. If the community still feels the idea is too radical, using an EXPIRED or CANTFIX resolution would still solve my problem. If we were to do that we might as well not do anything to old bugs automatically at all, because it's about as easy to customize a search to 'fedora 14, fedora 15, fedora 16, rawhide' as it is to customize it to 'no bugs with keyword EXPIRED'. Not quite: you don't have to remember which Fedora versions are maintained, or alternatively, update your saved queries every six months. And aside from search, marking expired bugs has the important function of cluing in the reporter that they should expect no action under the expiration policy. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Thu, 04 Nov 2010 16:10:17 -0400, Matt McCutchen wrote: On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319). This is my problem with the auto closing also. Leaving a bug open allows a more dedicated maintainer to come along (even years later) and actually fix or even apply patches that are still relevant without wasting time with bugs that we're actually looked at and legitimately closed. Years later pretty much every bug will be irrelevant thanks to the underlying changes that happen with every release and asking submitters to verify that the bug is still there is the right way to go. After all 8 out of 10 abrt submitted bugs against Eclipse stays months with questions and needinfo flags and no response from submitters. Note that I'm not saying these bugs shouldn't be submitted sometimes even just because for the 2 submitters that answer questions but I definitely don't want to waste my time closing the rest of them. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. This is the best we can do no matter what we want to do! P.S. Believe me having open bugs that both the packager and the submitter care for are useless and these are the kind of bugs that get auto closed. If one of them cares he will change the version flag. Oh and looking at a list of hundreds bugs makes things close to impossible to put priorities, fix and improve the situation. Alexander Kurtakov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Thu, 04 Nov 2010 16:10:17 -0400, Matt McCutchen wrote: On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319). This is my problem with the auto closing also. Leaving a bug open allows a more dedicated maintainer to come along (even years later) and actually fix or even apply patches that are still relevant without wasting time with bugs that we're actually looked at and legitimately closed. Years later pretty much every bug will be irrelevant thanks to the underlying changes that happen with every release and asking submitters to verify that the bug is still there is the right way to go. After all 8 out of 10 abrt submitted bugs against Eclipse stays months with questions and needinfo flags and no response from submitters. Note that I'm not saying these bugs shouldn't be submitted sometimes even just because for the 2 submitters that answer questions but I definitely don't want to waste my time closing the rest of them. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. This is the best we can do no matter what we want to do! P.S. Believe me having open bugs that both the packager and the submitter DON'T care for (sorry for the typo) care for are useless and these are the kind of bugs that get auto closed. If one of them cares he will change the version flag. Oh and looking at a list of hundreds bugs makes things close to impossible to put priorities, fix and improve the situation. Alexander Kurtakov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Thu, 2010-11-04 at 16:10 -0400, Matt McCutchen wrote: On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, That's, um, exactly the process we're discussing here. We close all bugs for a given release when that release goes EOL. (I forget what resolution is used, it may well be WONTFIX). We send a warning note to all bugs that will be closed under this process, a short while before they're closed, so the reporters can check if they exist in a newer version and bump the report to that version to keep it open, if they like. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Fri, 05 Nov 2010 09:14:08 +0200, Alexander Kurtakov wrote: On Thu, 04 Nov 2010 16:10:17 -0400, Matt McCutchen wrote: On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319). This is my problem with the auto closing also. Leaving a bug open allows a more dedicated maintainer to come along (even years later) and actually fix or even apply patches that are still relevant without wasting time with bugs that we're actually looked at and legitimately closed. Years later pretty much every bug will be irrelevant thanks to the underlying changes that happen with every release and asking submitters to verify that the bug is still there is the right way to go. After all 8 out of 10 abrt submitted bugs against Eclipse stays months with questions and needinfo flags and no response from submitters. Note that I'm not saying these bugs shouldn't be submitted sometimes even just because for the 2 submitters that answer questions but I definitely don't want to waste my time closing the rest of them. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. This is the best we can do no matter what we want to do! P.S. Believe me having open bugs that both the packager and the submitter care for are useless and these are the kind of bugs that get auto closed. If one of them cares he will change the version flag. Oh and looking at a list of hundreds bugs makes things close to impossible to put priorities, fix and improve the situation. I understand what your saying. After some consideration, my issues are: 1. I don't respond to autobots. 2. If the maintainer doesn't care, I don't care. Thus I'm not gonna tick of some version flag or something. I think what would help moving forward, (without having to do away with the autobots, which I welcome) is what Matt said... that the autobots did not CLOSE, but had some different status, such as: AUTO-CLOSED. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Marking zapped bugs
On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319). -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Thu, 04 Nov 2010 16:10:17 -0400, Matt McCutchen wrote: On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319). This is my problem with the auto closing also. Leaving a bug open allows a more dedicated maintainer to come along (even years later) and actually fix or even apply patches that are still relevant without wasting time with bugs that we're actually looked at and legitimately closed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
