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=version&y_axis_field=resolution&query_format=report-table&product=Fedora&format=table&action=wrap) [2] https://bugzilla.redhat.com/report.cgi?x_axis_field=version&y_axis_field=resolution&query_format=report-table&product=Fedora&emailreporter1=1&emailtype1=exact&email1=matt%40mattmccutchen.net&format=table&action=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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
