Fwd: closing out old bugs of unmaintained releases

[Jon Stanley]

On Jan 5, 2008 11:47 AM, Michael Schwendt
<mschwendt.tmp0701.nospam at arcor.de> wrote:

> Better? I doubt that. Many a bug reporter will be annoyed when after
> months or a year of ignoring a ticket and not fixing the bug somebody
> comes along and puts pressure on the reporter to allocate time for
> retesting.

That exact phenomenon  is what led me down this road (not this
particular course of action, but the realization that something had to
be done). [1].  I was bound and determined to end that cycle, and have
more instances like [2].

> t is even more rude to close such old bugs as WONTFIX or
> INSUFFICIENT_DATA. When only after the EOL of a distribution version there
> is activity within a ticket, that is like saying "we didn't care about
> your bug report this time, and we don't promise either that we look into
> the issue this time".

Is there some other reasonable course of action?  I'm sure that there
will be people with that perception, but I'm not sure what to do about
it.  I'm remembering back to my high school days now, when a teacher
used to tell me (and attributed it to someone else, but I can't for
the life of me remember who) "you can please some of the people all
the time, you can please all of the people some of the time, but you
can't please all the people all the time".

> Actually a reporter expects a package maintainer to
> evaluate a new report ASAP and make use of NEEDINFO states ASAP, so
> _sufficient data_ could be provided while the issue is _hot_. The packager
> ought to tell whether the provided data are insufficient and whether the
> problem is reproducible.

Either that or a triager to do the same.  People do not expect their
bugs to be magically fixed (some do, but those people are unreasonable
IM[NS]HO).  What they expect is someone to say "yes, we have received
this report.  Your voice is heard.  Maybe I'll poke a developer about
this".  Part of the job of a good triage team is maintainer/developer
interaction.

> When however it takes too long for the packager
> to handle a bug report, that increases the risk that the reporter moves on
> with different sofware/release or abandoning to use the software that
> causes trouble.

See [1]

> Please don't forget that bug reporters have limited time only, too.

Agreed.  Which is why mass-closing is such an appealing thing from
both sides of the fence.  It's been mentioned in this thread (not sure
if on this list or another, I'll go back and look), that the message
used to mass-close should basically admit the fact that we know that
we have a problem, and that we are taking action to fix the problem in
the future so that we don't get into this state again.

> Bug triagers should focus on filling a queue with tickets, where package
> maintainers commit to taking a serious look at those tickets.

I think that one of my proposals is going to be a fedora-triage flag
or something similar.  Maintainers can look at that and know that the
bug has been reviewed by a triager, that it's not a duplicate, and
that the priority/version/component settings on the bug are sane.

> The NEEDINFO
> state should be used when there is committment to moving forward with a
> ticket, not just to give the reporter something to do after a long of no
> interest in the report.

Are you saying that triagers should not use NEEDINFO for current bugs?
 At that point, there's not developer commitment, there is triager
commitment.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=204883
[2] https://bugzilla.redhat.com/show_bug.cgi?id=427157