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

Re: reopening bugs closed by removal after package reintroduction?

On Wed, May 13, 2020 at 05:13:45AM -0000, Sune Vuorela wrote:

> But I guess it also depends on if it is one bug that needs work, or a
> "Thanks for your contribution to Debian by maintainig this package. Now
> also walk thru these 1000 old crap that probably is irellevant
> today"-experience

I see two imperfect sides to this. On one side, as a user I report a
bug, the package drops out of Debian, the bug is ignored for a year,
then closed, the package comes back in Debian, buggy as before, and to
add insult to injury, I need to go and reopen the bug again.

On the other side, as you say, I want to package something that used to
be in Debian 5 years ago, get it into the archive, and suddenly have to
triage a number of zombie bugs.

I think there are extreme cases to both sides: a maintainer who's been
unresponsive on an important package leaving tons of users frustrated;
an old package which was popular enough to have tons of bugs, whose code
has evolved significantly so that those bugs are all mostly irrelevant
by now. Even something like, pypotetically, Gnu Interactive Tools
dropping out of Debian, getting its bugs closed, then one packages git
and gets all the previous git bugs assigned, all irrelevant.

I would however guess that, for a majority of cases, we are probably
talking about a bunch of bugs to triage, and I would rather introduce a
practice of risking having to triage some bugs more, than a way of
losing valid bugs along the way. Especially given that the time to
triage a bug should in theory be shorter than the time it took to find
it and report it, given also that the maintainer could ask users for

I prefer a default of remembering which bugs were closed by the package
leaving the archive, and reopening them when the package comes back.

When that becomes insane, I would like to look at how to make it less
insane, which might also help in other situations. For example:

 - a [semi]automated way of writing to the bug saying "this is part of a
   number of bugs in an old version of the package that disappeared from
   Debian. The package has now been reintroduced after upstream
   progressed significantly, and we need help figuring out of this
   issue is still present. Could you help with triaging? This bug will
   be automatically closed in 6 months if there is no interest"
 - a way of previewing the list of bugs that would be reopened, and have
   the maintainer decide whether to keep them closed, reopen all of
   them, or pick some to reopen
 - having a way of marking bugs as "needs-triage", and encourage group
   of users to go through such bugs, try to reproduce them, and either
   close them as fixed, or report them as still found, or add clearer
   instructions for reproducing

If the problem is "one'd end up with lots of old bugs to triage", I'd
rather improve the way we get bugs triaged.

In (too) many other projects I have the experience of opening a bug as
good as I can, being ignored for years, except for a bot that
occasionally tells me "if you don't reply to this I'll close the bug and
it's your fault for not caring".


GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

Attachment: signature.asc
Description: PGP signature

Reply to: