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=Fedora&product=Fedo... . 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.