On 24/08/25 at 23:36 +0200, Niels Thykier wrote: > Don Armstrong: > > Thanks for the report! > > > > On Sun, 24 Aug 2025, Niels Thykier wrote:n > > > I feel debbugs could just auto-done these after a delay (like 30 days) > > > once the last affected version disappears and there is at least one > > > fixed version. > > > > The way to fix this is to not close bugs using fixed, but to close them > > using -done when they are first completed. > > > > Using -done notifies the submitter and has a bunch of other nice > > properties that just setting fixed doesn't. > > > > I agree that this is the official best practice for how to close a bug, and > I understand why it is the best practice. But it is also not a very useful > answer to this problem, which is me questioning a failure mode where the > official best practice was not followed. The bug being in a pseudo-open > state like this does not notify the submitter any sooner nor trigger any of > the nice properties of a proper -done. The bug just rots there forever... > > I discovered these three by pure chance, and I only noticed them because > they were RC in a package that was not scheduled for auto-removal (the RC > bugs was listed on tracker.d.o). > > I have run into this numerous time in the past, and I will run into this > into the future if the status quo does not change. That is why I filed this > bug. In my view, the status quo leads to zombie bugs that slowly rots > forever. > > > There's an argument to be made that we should instead warn loudly if a > > bug has been fixed without having been -done so the person marking it > > fixed knows to send a message to -done as well. > > > > That is certainly also a solution. However, whatever fix you go with, I > would recommend it is something that tracker.d.o can display (emails get > lost, I skip the bug pages for a package preferring to jump directly to > known bugs, etc.). > Added bonus, if it also reports the "when `found version` == `fixed > version` then the bug is not fixed"-issue that has caught people by surprise > as well (assuming that is still a thing). > > Jumping to a solution / idea spewing mode: > - Export a list of bugs per package that has one or more potential > problems for tracker.d.o and other services.
UDD can provide a first list of candidates with e.g select id, source from bugs where not (affects_oldstable or affects_stable or affects_testing or affects_unstable or affects_experimental) and status != 'done' and source in (select source from sources) -- source exists (not pseudo-package) order by id; (4961 bugs) Some of them look like b0rked versions information (#1111558, #1111626) Lucas
