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 help. 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". Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>
signature.asc
Description: PGP signature
