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.
cu
Adrian
Reply to: