From 849ea46b64543ec5725c742096962698f6e4a195 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=B6rg=20Thalheim?= <joerg@thalheim.io>
Date: Sun, 14 Jul 2024 07:05:28 +0200
Subject: [PATCH] [RFC 0180] Remove broken and unmaintained leaf packages

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

Co-authored-by: Priyanshu Tripathi <priyanshu@getpsyched.dev>
---
 rfcs/0180-broken-package-removal.md | 91 +++++++++++++++++++++++++++++
 1 file changed, 91 insertions(+)
 create mode 100644 rfcs/0180-broken-package-removal.md

diff --git a/rfcs/0180-broken-package-removal.md b/rfcs/0180-broken-package-removal.md
new file mode 100644
index 000000000..6bd70ec41
--- /dev/null
+++ b/rfcs/0180-broken-package-removal.md
@@ -0,0 +1,91 @@
+---
+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 RFCs defines under what conditions we remove broken and unmaintained leaf packages.
+The RFC does not have the ambition to define all reasons to remove a package but
+instead focuses on simple rules that can be automated.
+
+# Motivation
+
+[motivation]: #motivation
+
+Broken and unmaintained packages still cost us valuable time.
+Broken packages still have to be evaluated to some extent
+and unmaintained packages might still have to rebuild when one of their dependencies changes.
+Removing unmaintained/unused code hopefully increases the overall package quality and helps us
+to save resources.
+Because it is easy to add packages, it should be also easy to remove them, ideally automated.
+
+# Detailed design
+
+[design]: #detailed-design
+
+## Broken Packages
+
+Packages that are marked as broken unconditionally platforms should be removed after one full NixOS release cycle.
+If the package had dependencies, those dependencies are also marked as indirectly broken.
+If they are not functional without the broken package, they should be removed as well.
+
+## Unmaintained packages
+
+Packages with an empty maintainer field that does not have packages depending on it, should
+be removed after 2 months. Ideally we have an automation or semi-automation that creates pull requests for that (see future work).
+
+If a NixOS module depends on any of removed package, this module gets removed as well, if it is non-functional without the package.
+In `pkgs/top-level/aliases.nix` we can link to the pull request that removed the package,
+to make it easier for people to recover the nix expression.
+
+In the pull request that removes a package, we also will ping people that have modified/updated the package excluding those that only
+touched the package as part of treewide.
+
+# Examples and Interactions
+
+[examples-and-interactions]: #examples-and-interactions
+
+-
+
+# Drawbacks
+
+[drawbacks]: #drawbacks
+
+Some maintained packages might still have users that won't be able to use the package,
+but the hope is that the removal of unmaintained package will lead to these people
+stepping up as a maintainer. Recovering from the git history should be easy in that case.
+
+# Alternatives
+
+[alternatives]: #alternatives
+
+Keep all packages.
+
+# Prior art
+
+[prior-art]: #prior-art
+
+- Most Linux distributions have rules around removing unmaintained packages i.e. Debian.
+- [Nixpkgs eval time is increasing too fast](https://github.com/NixOS/nixpkgs/issues/320528):
+  This issue discusses how we can improve the evaluation time.
+
+# Unresolved questions
+
+[unresolved]: #unresolved-questions
+
+?
+
+# Future work
+
+[future]: #future-work
+
+- Write automation that will open pull request to remove packages.
+- Add deprecation warnings for packages/modules that are about to become removed, so that potential users are notified