[FWIW, I am not a Debian Developer, Debian Maintainer, person who packages software for Debian, or even an active user of Debian Linux. I do follow a bunch of the mailing lists, including this one, and d/l and make available on BitTorrent a number of the amd64 main and live ISOs. Yay, me. Basically, I'm a random bystander eating (virtual) popcorn here on the Internets. Oh, I should mention, I'm a dog (which you didn't know). WRT AI/LLM-generated content, I use GMail, I'll probably accept Speeling Feexes it offers, maybe not so much suggestions on tone and content. Otherwise, this is entirely human-created (well, canine-created) content, not AI generated stuff. Can't you tell?]
On Sun, Nov 8, 2026 at 4:42 PM Lars Uffmann <[email protected]> wrote: > On 2026-11-08 20:09:45, Simon Quigley wrote: > > There's also another argument to be made about the age of the bugs. It > > would be one thing if there was a recommendation not to sponsor from one DD > > and another DD did it anyway. On the other hand, for these bugs, *none* of > > the DDs interested in sponsoring packages have picked them up, > > recommendation against or not. That should speak for something. I'm > > absolutely +1 on closing the bugs that are older than a few months at this > > point, if they match the criteria of self-authored. The downside to > > automatically closing those old bugs is that we might actually miss a valid > > one, so should be handled manually. > > As someone whose RFS is several months old by now, who has actively sought > reviewers, gotten reviews, implemented reviewer comments and is currently ~1 > month waiting for a potential sponsor feedback after 2 months with no > sponsors, I'd very much appreciate if you took the time to manually close RFS > issues to see which ones have had the uploader put serious effort in. I'll note that, presumably, RFS bugs closed under this policy can be un-closed by the original bug submitter if they see fit to do so. (Such an un-closing *might* be evidence that the software the RFS bug references actually does potentially have an active maintainer, as opposed to someone who wants to drop version 1.0.0 (or 0.1.0) of a package and then abandon it to bit-rot.) I'll also note that, for example, Mr. Uffmann's proposed packages presumably don't meet the reason given for this proposed action, since he claims he has actively sought feedback and received reviews, implemented changes to the package based on those reviews, would presumably update the proposed package if the upstream author of the software made a new release, etc etc etc. Whereas a person who receives a review with a +moreinfo flag but then doesn't do anything with it for a fair amount of time (maybe 3 months without a response or activity to the +moreinfo might be good?) does seem like a candidate for bug closing under these proposed grounds. If I might suggest, based on what I've observed being done under other automated and/or mass bug filings... (1) Determine a set of criteria for RFS bugs you want to close, for instance: (a) bugs of at least a certain age are candidates for closing; (b) bugs that have received reviews / +moreinfo tags, but then haven't visibly acted upon those reviews for a certain amount of time (1 month, 2 month, 3 months?) are candidates if they are at least the certain age from (a) less the amount of time they haven't visibly acted upon their reviews (for instance, if (a) applies at 9 months, and (b) is a package that received a review 2 months ago but hasn't acted upon it, then if the package is at least 9 - 2 = 7 months old it's a candidate for closing; (c) bugs that have received reviews / +moreinfo tags, but then have demonstrated activity / responses to those reviews, for instance by submitting updated packaging responding to the reviews, clearing the +moreinfo tags, etc, are candidates for closing Only If they are older than the greater of (a) or a certain significant amount of time (say, 6 months?) after the last demonstrated activity / response; (d) bugs that have not received reviews / +moreinfo tags, but otherwise demonstrate continued interest in / activity concerning the package (e.g.upstream makes a new release and it is packaged and put up as a new version of the software with the RFS bug) should be treated similarly to bugs in (c), perhaps with an even greater significant amount of time (no DD has demonstrated interest in the proposed package but the RFS bug submitter is still working on it anyway, that should be encouraged?); (e) etc etc etc. (2) Determine the set of RFS bugs that are candidates for closing per (1). Post that list here. Give interested parties (RFS bug submitters, DDs, people following the list) a couple of weeks or a month to agree with or challenge the presence of a bug on the list. For example, a RFS bug submitter might say "Upstream is releasing a new version of the software in N small weeks and I will be packaging and uploading it in N small weeks after it comes out" or "I've been Really Busy with Day-Job, the review / +moreinfo slipped through the cracks, I intend to respond to the review with a new version of the package within N small weeks from now". A DD might say "I am interested in the package this RFS bug is for, but I've been Really Busy with Day-Job. I commit to either sponsoring the package as it is now, or else providing a review of what needs to be changed before I would be willing to sponsor it, within N not quite so small weeks from now". (3) Once the final list of candidate RFS bugs to be closed has been determined, send a message to each bug on the list saying "This bug is a candidate for being closed due to inactivity / age on [date]. To prevent this bug from being closed, you need to do X, Y, and Z to demonstrate activity / make the package suitable for sponsoring / etc." (4) On [date], each bug that hasn't done whatever (3) said it needed to do is closed. (5) Rinse and repeat on some sort of regular schedule (every 3 months? Every 6?). Hopefully some of this can be automated over time, to make it easier to keep doing this on a regular basis. Hope this is of some use, interest. Thanks for giving me some of your time in reading this. I hope you find it helpful. Be well. Joseph
