summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMichał Górny <mgorny@gentoo.org>2020-01-12 08:17:58 +0100
committerMichał Górny <mgorny@gentoo.org>2020-01-19 11:51:33 +0100
commite8c1bf40fb65daf1e90112a21296cb61e06b1fbb (patch)
treec0e698257fbb592ad3b38027eef24d5dff9f94ea /keywords.rst
parentAdd a chapter on maintainers (diff)
downloadpolicy-guide-e8c1bf40fb65daf1e90112a21296cb61e06b1fbb.tar.gz
policy-guide-e8c1bf40fb65daf1e90112a21296cb61e06b1fbb.tar.bz2
policy-guide-e8c1bf40fb65daf1e90112a21296cb61e06b1fbb.zip
Rekeywording & stabilization rules
Closes: https://bugs.gentoo.org/705474 Closes: https://github.com/gentoo/policy-guide/pull/2 Signed-off-by: Michał Górny <mgorny@gentoo.org>
Diffstat (limited to 'keywords.rst')
-rw-r--r--keywords.rst45
1 files changed, 45 insertions, 0 deletions
diff --git a/keywords.rst b/keywords.rst
index 5dcbc77..272dca4 100644
--- a/keywords.rst
+++ b/keywords.rst
@@ -1,6 +1,51 @@
Keywording and stabilization
============================
+.. index:: keywords; rekeywording
+
+Rekeywording on dropped keywords
+--------------------------------
+:Source: QA
+:Reported: by pkgcheck and repoman
+
+The developer removing keywords from a package (e.g. due to new
+dependencies) must file a rekeywording bug asking for the package being
+retested. This rule can be exempted if the package is known not to work
+(anymore) on the arch in question.
+
+*Rationale*: rekeywording on minor architectures often takes a long
+time. If a developer neglects to request it immediately, it negatively
+affects other developers who in the future either want to stabilize
+a new version or to remove an old version.
+
+
+.. index:: keywords; stabilizing new versions
+
+Stabilizing new versions
+------------------------
+:Source: QA
+:Reported: by pkgcheck
+
+Whenever requesting a stabilization of a new version of the package,
+the developer must CC *all* arches that had at least one previous stable
+version of the package in question, and that still have ~arch keywords
+in the stabilized version. This applies to experimental architectures
+as well.
+
+The stabilization request can be closed and old stable version removed
+once all non-experimental architectures have processed the stabilization
+request. However, the remaining arch teams should be kept CC-ed in case
+they wanted to process the bug.
+
+*Rationale*: there were some cases of developers requesting
+stabilization only of a subset of architectures they were personally
+interested in. This meant some other developer had to independently
+request stabilization on remaining architectures which only meant
+a duplication of effort and unnecessary confusion over which version
+is stable and whether arch teams are slacking or stabilization was not
+requested on remaining architectures in the first place.
+
+
.. index:: keywords; removing stable
Removing stable keywords