# DEP

Published articles for DEP.

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