diff options
| author |   Michał Górny <mgorny@gentoo.org> | 2020-01-12 08:17:58 +0100 |
|---|---|---|
| committer | Michał Górny <mgorny@gentoo.org> | 2020-01-19 11:51:33 +0100 |
| commit | e8c1bf40fb65daf1e90112a21296cb61e06b1fbb (patch) | |
| tree | c0e698257fbb592ad3b38027eef24d5dff9f94ea /keywords.rst | |
| parent | Add a chapter on maintainers (diff) | |
| download | policy-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.rst | 45 |
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 |