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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
