aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSam James <sam@gentoo.org>2022-01-12 04:26:44 +0000
committerSam James <sam@gentoo.org>2022-01-22 21:34:54 +0000
commite61cbdca52edcc1ff6bac20577722793703997ce (patch)
treec02ee205434018de791d62a46a915e85e794f5ff /keywording
parentebuild-maintenance/package-moves: minor grammar and formatting nits (diff)
downloaddevmanual-e61cbdca52edcc1ff6bac20577722793703997ce.tar.gz
devmanual-e61cbdca52edcc1ff6bac20577722793703997ce.tar.bz2
devmanual-e61cbdca52edcc1ff6bac20577722793703997ce.zip
keywording: add explanatory text on maintainer obligations
Inspired partly by a discussion on a GitHub pull request [0]. [0] https://github.com/gentoo/gentoo/pull/23735 Signed-off-by: Sam James <sam@gentoo.org>
Diffstat (limited to 'keywording')
-rw-r--r--keywording/text.xml23
1 files changed, 23 insertions, 0 deletions
diff --git a/keywording/text.xml b/keywording/text.xml
index cc10166..ed6b6d1 100644
--- a/keywording/text.xml
+++ b/keywording/text.xml
@@ -244,6 +244,29 @@ to do this.
<body>
<p>
+If a package has stable keywords, maintainers should regularly (subject to the
+rules below) file stabilization bugs for their packages, ideally approximately
+every 30 days after a new version is added. If a bug report for stabilization
+is filed by somebody else, the maintainer should respond with an
+acknowledgement ("ACK") if the ebuild is ready, and a negative
+acknowledgement ("NAK") if not.
+</p>
+
+<p>
+Previous stable keywords should not be dropped without good cause and it is
+courteous to ping members of the relevant arch team first. Maintainers must not
+drop stable keywords simply because they don't have access to a platform: this
+is what Gentoo's arch teams are here for.
+</p>
+
+<p>
+By convention, these bugs are assigned to package maintainers, but the only
+action expected from maintainers is to acknowledge or reject the
+stabilization rather than carry out additional testing on each required
+architecture themselves.
+</p>
+
+<p>
Stabilization, i.e., moving an ebuild from <c>~arch</c> ("testing") to
<c>arch</c> ("stable"), is done by the relevant architecture teams. If you have
access to exotic hardware but are not on the arch teams, you may wish to make