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

Re: Control header sent with done email didn't do what I expected, should it have?

* Russ Allbery <rra@debian.org> [230925 12:43]:
> Marvin Renich <mrvn@renich.org> writes:
> > I've seen differing opinions about closing "wontfix" bugs, but as a
> I think it's a trade-off.

Which is why I said there are differing opinions.  This has come up on
this list before.

> There are some bugs that seem unlikely to ever
> come up again or that aren't helpfully worded, and I'm more willing to
> close those.


> Also, in the abstract, I don't like using the BTS as a documentation
> system, which is sort of what collecting wontfix amounts to.  If it's

Except that if it looks like a bug to me, I am going to fire up
reportbug without looking at README.Debian, and I think many users do
the same.  But, I do go through existing bugs to try to avoid
duplication.  I know not everyone does, but they should.

I feel that even though this was not the original intent of the BTS, it
is the most useful and pragmatic place to document this sort of thing.
Documenting it in a bug script may be more in line with its intended
use, but is probably a poorer use of Debian resources, as it uses Debian
and mirror archive space and download resources (both Debian and user)
for something that is only going to come up every 10,000 package

> something that I think is going to come up a lot, it feels better to put
> it into the actual documentation (README.Debian, a bug script if it's
> reported really often, etc.).  You're also expecting everyone filing a bug
> to read through all the existing wontfix bugs (at least their titles),
> which in some cases is fine but in some cases can become overwhelming.

I wasn't trying to start a lengthy discussion or get Debian to make an
official policy, just stating a preference.  I expect that most
maintainers use good judgement, and adding the reasoning for my
preference might help them decide which wontfix bugs to close and which
to leave open.


Reply to: