[RFC 0180] Remove broken and unmaintained leaf packages

Update rfcs/0180-broken-package-removal.md

Co-authored-by: Priyanshu Tripathi <[email protected]>

rfcs/0180-broken-package-removal.md

@@ -0,0 +1,92 @@
+---
+feature: broken-package-removal
+start-date: 2024-07-14
+author: Jörg "Mic92" Thalheim
+co-authors:
+shepherd-team:
+shepherd-leader:
+related-issues:
+---
+
+# Summary
+
+[summary]: #summary
+
+This RFC defines the conditions under which we remove broken and unmaintained leaf packages.
+The RFC does not aim to define all possible reasons for removing a package but instead focuses on simple, automatable rules.
+Since this document serves as a guideline for automatic package removal, it also allows for the possibility of removing a package earlier for other reasons.
+
+# Motivation
+
+[motivation]: #motivation
+
+Broken and unmaintained packages still consume valuable time.
+Broken packages need to be evaluated to some extent, and unmaintained packages might still need to be rebuilt when one of their dependencies changes.
+Removing unmaintained or unused code should improve overall package quality and help save resources.
+Since adding packages is easy, removing them should also be simple, ideally automated.
+
+# Detailed Design
+
+[design]: #detailed-design
+
+All packages marked as broken or unmaintained will be removed after a full NixOS release cycle.
+For example, if `hello-unmaintained` is marked as unmaintained in 23.11, it can be removed from master after the 24.05 release.
+
+## Broken Packages
+
+Packages that are unconditionally marked as broken on all platforms are candidates for removal.
+If a package has dependent packages, those dependent packages will also be marked as indirectly broken.
+If the dependent packages cannot function without the broken package, they should also be removed.
+For example, if a library is broken and an application depends on it, the application will also be removed.
+
+## Unmaintained Packages
+
+We will add an "unmaintained" warning for all packages with an empty maintainer field that do not have any dependent packages.
+Ideally, we will have automation or semi-automation in place to create pull requests for this process (see future work).
+
+If a NixOS module depends on any removed package and is non-functional without it, the module will be removed as well.
+In `pkgs/top-level/aliases.nix`, we can link to the pull request that removed the package, making it easier for users to recover the nix expression if needed.
+
+In the pull request that removes a package, we will also ping the people who have modified or updated the package, excluding those who only touched the package as part of a tree-wide update.
+
+# Examples and Interactions
+
+[examples-and-interactions]: #examples-and-interactions
+
+- A release manager or another contributor marks `packageA` as broken in 23.11, notifying the maintainer.
+- They have one full release cycle, as described, to fix `packageA`.
+- After the 24.05 release, `packageA` can be automatically removed from the nixpkgs master branch, as outlined in this RFC.
+
+# Drawbacks
+
+[drawbacks]: #drawbacks
+
+Some unmaintained packages may still have users who will no longer be able to use them, but the hope is that removing unmaintained packages will encourage these users to step up as maintainers.
+In such cases, recovering the package from the git history should be relatively easy.
+
+# Alternatives
+
+[alternatives]: #alternatives
+
+- Keep all packages.
+- Archive removed nix expressions. Note that this RFC does not prevent this effort from being implemented in addition.
+
+# Prior Art
+
+[prior-art]: #prior-art
+
+- Most Linux distributions have rules for removing unmaintained packages, e.g., [Debian](https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#orphaning-a-package).
+- [Nixpkgs eval time is increasing too fast](https://github.com/NixOS/nixpkgs/issues/320528): This issue discusses ways to improve evaluation time.
+
+# Unresolved Questions
+
+[unresolved]: #unresolved-questions
+
+None.
+
+# Future Work
+
+[future]: #future-work
+
+- Develop automation that opens pull requests to remove packages.
+- Add deprecation warnings for packages scheduled for removal to notify potential users.