[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Consensus on closing old bugs

On Mon, Feb 13, 2023 at 08:05:50AM -0800, Russ Allbery wrote:
> So in short I agree with Holger: it really depends.  It's rude to ask
> someone to do a bunch of work when you have no intention of following
> through on that work, which happens a lot when new volunteers do bug
> triage without the skills required to follow up on the responses to that
> triage.  But also if you're never going to work on a bug and you don't
> think it serves any documentation purpose, it's okay to close it as
> wontfix and arguably better communication to the bug reporter than leaving
> it open and creating the illusion that you might fix it some day.

A maintainer closing a bug based on its contents is quite different from
"close bugs simply because they are old".

There is a certain stupidity if a (human or nonhuman) bot blindly asks 
the submitter whether the "typo in the manpage" bug is still reproducible,
or closes it simply because it is old.

How a maintainer deals with "systemd: Please port to Hurd" kind of bugs
is a different topic.

> The more prominent the
> package and the larger the unsophisticated user base, the more aggressive
> you have to be about closing bugs if you want the open bug list to be a
> useful artifact for guiding development.

I would say the typical Debian approach in such situations tends to be 
to optionally look at older bugs once when you adopt a package or join 
the packaging team, and afterwards only react to bug email.

> Or one can just use an autoclose bot, I guess, which is basically the
> equivalent of one of those email autoreplies that says "this mailbox is
> unattended and no one will ever read your email."  :)  And, to be honest,
> if that's the reality of the situation, maybe better to know than not!

I am sometimes getting an email from the BTS that this "typo in the manpage"
bug I reported 20 years ago has just been fixed in the "New maintainer"
upload of a package.

When working on orphaned packages or doing NMUs, it is also often useful 
for me to see the amount/age/contents of bugs in a package as an 
indication in what state it is.


Reply to: