Marking zapped bugs

[Matt McCutchen]

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=Fedora&version=14&version=15&version=16&version=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