# packages removing

Published articles for packages removing.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Bits from the DPL

DevFeed: [Bits from the DPL](<https://devfeed.tech/articles/bits-from-the-dpl-47072.md>)

Original publisher: [Read original article](<https://bits.debian.org/2024/09/bits-from-the-dpl-September.html>)

Author: Andreas Tille

Published: 2024-09-01T22:00:00Z

Content type: opinion

Language: en

Sources: [Bits from Debian](<https://devfeed.tech/sources/bits-from-debian.md>)

Topics: [Debian](<https://devfeed.tech/topics/debian.md>), [Maintainers](<https://devfeed.tech/topics/maintainers.md>), [Automation](<https://devfeed.tech/topics/automation.md>)

Tags: [anniversary](<https://devfeed.tech/tags/anniversary.md>), [automatically](<https://devfeed.tech/tags/automatically.md>), [automation](<https://devfeed.tech/tags/automation.md>), [debian](<https://devfeed.tech/tags/debian.md>), [debianday](<https://devfeed.tech/tags/debianday.md>), [dep](<https://devfeed.tech/tags/dep.md>), [dpl](<https://devfeed.tech/tags/dpl.md>), [dpl-bits](<https://devfeed.tech/tags/dpl-bits.md>), [help](<https://devfeed.tech/tags/help.md>), [history](<https://devfeed.tech/tags/history.md>), [maintainers](<https://devfeed.tech/tags/maintainers.md>), [packages-removing](<https://devfeed.tech/tags/packages-removing.md>), [project](<https://devfeed.tech/tags/project.md>), [salsa](<https://devfeed.tech/tags/salsa.md>), [tiny-tasks](<https://devfeed.tech/tags/tiny-tasks.md>)

### AI overview

A Debian Project Leader update discusses proposals to remove long-unmaintained packages from unstable. It considers objective criteria, package ownership, social pressure on maintainers, and whether the removal process should be automated, semi-automated, or human-managed.

### Source excerpt

Dear Debian community, this are my bits from DPL for August. Happy Birthday Debian On 16th of August Debian celebrated its 31th birthday. Since I'm unable to write a better text than our great publicity team I'm simply linking to their article for those who might have missed it: https://bits.debian.org/2024/08/debian-turns-31.html Removing more packages from unstable Helmut Grohne argued for more aggressive package removal and sought consensus on a way forward. He provided six examples of processes where packages that are candidates for removal are consuming valuable person-power. I'd like to add that the Bug of the Day initiative (see below) also frequently encounters long-unmaintained packages with popcon votes sometimes as low as zero, and often fewer than ten. Helmut's email included a list of packages that would meet the suggested removal criteria. There was some discussion about whether a popcon vote should be included in these criteria, with arguments both for and against it. Although I support including popcon, I acknowledge that Helmut has a valid point in suggesting it be left out. While I've read several emails in agreement, Scott Kitterman made a valid point "I don't think we need more process. We just need someone to do the work of finding the packages and filing the bugs." I agree that this is crucial to ensure an automated process doesn't lead to unwanted removals. However, I don't see "someone" stepping up to file RM bugs against other maintainers' packages. As long as we have strict ownership of packages, many people are hesitant to touch a package, even for fixing it. Asking for its removal might be even less well-received. Therefore, if an automated procedure were to create RM bugs based on defined criteria, it could help reduce some of the social pressure. In this aspect the opinion of Niels Thykier is interesting: "As much as I want automation, I do not mind the prototype starting as a semi-automatic process if that is what it takes to get start