Merge branch 'nixos-unstable' of https://github.com/NixOS/nixpkgs

1 files changed, 14 insertions, 9 deletions

diff --git a/nixpkgs/CONTRIBUTING.md b/nixpkgs/CONTRIBUTING.md
index 177e6a4a687e..e30a4bb0f95e 100644
--- a/nixpkgs/CONTRIBUTING.md
+++ b/nixpkgs/CONTRIBUTING.md
@@ -483,17 +483,17 @@ The oldest supported release (`YYMM`) can be found using
 nix-instantiate --eval -A lib.trivial.oldestSupportedRelease
 ```
 
-The release branches should generally not receive any breaking changes, both for the Nix expressions and derivations.
-So these changes are acceptable to backport:
-- New packages, modules and functions
-- Security fixes
-- Package version updates
-  - Patch versions with fixes
-  - Minor versions with new functionality, but no breaking changes
+The release branches should generally only receive backwards-compatible changes, both for the Nix expressions and derivations.
+Here are some examples of backwards-compatible changes that are okay to backport:
+- ✔️ New packages, modules and functions
+- ✔️ Security fixes
+- ✔️ Package version updates
+  - ✔️ Patch versions with fixes
+  - ✔️ Minor versions with new functionality, but no breaking changes
 
 In addition, major package version updates with breaking changes are also acceptable for:
-- Services that would fail without up-to-date client software, such as `spotify`, `steam`, and `discord`
-- Security critical applications, such as `firefox` and `chromium`
+- ✔️ Services that would fail without up-to-date client software, such as `spotify`, `steam`, and `discord`
+- ✔️ Security critical applications, such as `firefox` and `chromium`
 
 ### Changes causing mass rebuilds
 [mass-rebuild]: #changes-causing-mass-rebuilds
@@ -535,6 +535,11 @@ To get a sense for what changes are considered mass rebuilds, see [previously me
 
     The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).
 
+  When adding yourself as maintainer, in the same pull request, make a separate
+  commit with the message `maintainers: add <handle>`.
+  Add the commit before those making changes to the package or module.
+  See [Nixpkgs Maintainers](../maintainers/README.md) for details.
+
 ### Writing good commit messages
 
 In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand *why* a change was made. While this information usually can be found by digging code, mailing list/Discourse archives, pull request discussions or upstream changes, it may require a lot of work.