| 1 |
commit: e8c1bf40fb65daf1e90112a21296cb61e06b1fbb |
| 2 |
Author: Michał Górny <mgorny <AT> gentoo <DOT> org> |
| 3 |
AuthorDate: Sun Jan 12 07:17:58 2020 +0000 |
| 4 |
Commit: Michał Górny <mgorny <AT> gentoo <DOT> org> |
| 5 |
CommitDate: Sun Jan 19 10:51:33 2020 +0000 |
| 6 |
URL: https://gitweb.gentoo.org/proj/policy-guide.git/commit/?id=e8c1bf40 |
| 7 |
|
| 8 |
Rekeywording & stabilization rules |
| 9 |
|
| 10 |
Closes: https://bugs.gentoo.org/705474 |
| 11 |
Closes: https://github.com/gentoo/policy-guide/pull/2 |
| 12 |
Signed-off-by: Michał Górny <mgorny <AT> gentoo.org> |
| 13 |
|
| 14 |
keywords.rst | 45 +++++++++++++++++++++++++++++++++++++++++++++ |
| 15 |
1 file changed, 45 insertions(+) |
| 16 |
|
| 17 |
diff --git a/keywords.rst b/keywords.rst |
| 18 |
index 5dcbc77..272dca4 100644 |
| 19 |
--- a/keywords.rst |
| 20 |
+++ b/keywords.rst |
| 21 |
@@ -1,6 +1,51 @@ |
| 22 |
Keywording and stabilization |
| 23 |
============================ |
| 24 |
|
| 25 |
+.. index:: keywords; rekeywording |
| 26 |
+ |
| 27 |
+Rekeywording on dropped keywords |
| 28 |
+-------------------------------- |
| 29 |
+:Source: QA |
| 30 |
+:Reported: by pkgcheck and repoman |
| 31 |
+ |
| 32 |
+The developer removing keywords from a package (e.g. due to new |
| 33 |
+dependencies) must file a rekeywording bug asking for the package being |
| 34 |
+retested. This rule can be exempted if the package is known not to work |
| 35 |
+(anymore) on the arch in question. |
| 36 |
+ |
| 37 |
+*Rationale*: rekeywording on minor architectures often takes a long |
| 38 |
+time. If a developer neglects to request it immediately, it negatively |
| 39 |
+affects other developers who in the future either want to stabilize |
| 40 |
+a new version or to remove an old version. |
| 41 |
+ |
| 42 |
+ |
| 43 |
+.. index:: keywords; stabilizing new versions |
| 44 |
+ |
| 45 |
+Stabilizing new versions |
| 46 |
+------------------------ |
| 47 |
+:Source: QA |
| 48 |
+:Reported: by pkgcheck |
| 49 |
+ |
| 50 |
+Whenever requesting a stabilization of a new version of the package, |
| 51 |
+the developer must CC *all* arches that had at least one previous stable |
| 52 |
+version of the package in question, and that still have ~arch keywords |
| 53 |
+in the stabilized version. This applies to experimental architectures |
| 54 |
+as well. |
| 55 |
+ |
| 56 |
+The stabilization request can be closed and old stable version removed |
| 57 |
+once all non-experimental architectures have processed the stabilization |
| 58 |
+request. However, the remaining arch teams should be kept CC-ed in case |
| 59 |
+they wanted to process the bug. |
| 60 |
+ |
| 61 |
+*Rationale*: there were some cases of developers requesting |
| 62 |
+stabilization only of a subset of architectures they were personally |
| 63 |
+interested in. This meant some other developer had to independently |
| 64 |
+request stabilization on remaining architectures which only meant |
| 65 |
+a duplication of effort and unnecessary confusion over which version |
| 66 |
+is stable and whether arch teams are slacking or stabilization was not |
| 67 |
+requested on remaining architectures in the first place. |
| 68 |
+ |
| 69 |
+ |
| 70 |
.. index:: keywords; removing stable |
| 71 |
|
| 72 |
Removing stable keywords |
Archives