| 1 |
commit: 449da7f72272a7f3c4b5c5a2761151fc553d7338 |
| 2 |
Author: Ulrich Müller <ulm <AT> gentoo <DOT> org> |
| 3 |
AuthorDate: Thu Jan 23 16:54:18 2020 +0000 |
| 4 |
Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org> |
| 5 |
CommitDate: Sat Jan 25 05:53:21 2020 +0000 |
| 6 |
URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=449da7f7 |
| 7 |
|
| 8 |
keywording: Include sections about stabilization. |
| 9 |
|
| 10 |
Remove the ebuild-maintenance/stabilization section (which resulted |
| 11 |
from the split of ebuild-maintenance/maintenance-tasks), and include |
| 12 |
it in keywording. Delete duplicate and outdated information. |
| 13 |
|
| 14 |
Closes: https://bugs.gentoo.org/648316 |
| 15 |
Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org> |
| 16 |
|
| 17 |
ebuild-maintenance/stabilization/text.xml | 119 ------------------------------ |
| 18 |
ebuild-maintenance/text.xml | 1 - |
| 19 |
keywording/text.xml | 83 +++++++++++++++++---- |
| 20 |
3 files changed, 69 insertions(+), 134 deletions(-) |
| 21 |
|
| 22 |
diff --git a/ebuild-maintenance/stabilization/text.xml b/ebuild-maintenance/stabilization/text.xml |
| 23 |
deleted file mode 100644 |
| 24 |
index b67c2b5..0000000 |
| 25 |
--- a/ebuild-maintenance/stabilization/text.xml |
| 26 |
+++ /dev/null |
| 27 |
@@ -1,119 +0,0 @@ |
| 28 |
-<?xml version="1.0"?> |
| 29 |
-<guide self="ebuild-maintenance/stabilization/"> |
| 30 |
-<chapter> |
| 31 |
-<title>Stabilizing and Upgrading Ebuilds</title> |
| 32 |
- |
| 33 |
-<section> |
| 34 |
-<title>Stabilizing ebuilds</title> |
| 35 |
-<body> |
| 36 |
- |
| 37 |
-<p> |
| 38 |
-Only architecture maintainers for a given architecture should mark packages as |
| 39 |
-stable on that architecture. The maintainer of the package should always be |
| 40 |
-contacted just in case there are reasons not to do so. The exception to this |
| 41 |
-is if you are part of an architecture team, in which case you may mark the |
| 42 |
-package stable for that architecture. If you are not part of an architecture |
| 43 |
-team, you should consult the guidelines below; if the architecture you are |
| 44 |
-looking for is not listed then please consult the relevant lead. |
| 45 |
-</p> |
| 46 |
- |
| 47 |
-<p> |
| 48 |
-You should <e>never</e> stabilize packages on architectures for which you |
| 49 |
-cannot test and instead you should file a bug to the relevant architecture |
| 50 |
-team, such as <c>sparc@g.o</c> asking them to stabilize the ebuild. |
| 51 |
-Alternatively, you may be able to find Gentoo developers on IRC who could help |
| 52 |
-you with your request. |
| 53 |
-</p> |
| 54 |
- |
| 55 |
-<p> |
| 56 |
-It is best to not use <c>arch-maintainers@g.o</c>, adding architecture |
| 57 |
-teams onto a bug's CC list individually instead. That way teams can remove |
| 58 |
-themselves from the list when they are done, giving a clear indication |
| 59 |
-of which teams still have to stabilize a package. |
| 60 |
-</p> |
| 61 |
- |
| 62 |
-</body> |
| 63 |
-</section> |
| 64 |
- |
| 65 |
-<section> |
| 66 |
-<title>Stabilization rules</title> |
| 67 |
-<body> |
| 68 |
- |
| 69 |
-<p> |
| 70 |
-SPARC: You must have prior permission from the arch lead. Usually we expect |
| 71 |
-you to be on the sparc alias for QA reasons, although other arrangements |
| 72 |
-can be made if you will only be working with a small group of packages. |
| 73 |
-</p> |
| 74 |
- |
| 75 |
-<p> |
| 76 |
-ALPHA: Maintainers may keyword their own packages but are reminded to inform |
| 77 |
-the Alpha team if they can help out with testing and keywording packages so |
| 78 |
-the team can keep an eye out for possible keywording mistakes. |
| 79 |
-</p> |
| 80 |
- |
| 81 |
-<p> |
| 82 |
-Exotic architectures (like alpha, ia64, sparc, hppa, ppc*) are short |
| 83 |
-on manpower, so it's best if you avoid opening stabilization bugs for |
| 84 |
-them unless it is absolutely necessary (eg, a reverse dependency for |
| 85 |
-your package). More about keywording policies can be found in the |
| 86 |
-<uri link="::keywording">keywording</uri> section. |
| 87 |
-</p> |
| 88 |
- |
| 89 |
-<p> |
| 90 |
-Some architectures (like m68k, mips, s390, sh) do not maintain a |
| 91 |
-stable keyword. So there is no use in marking a package stable for one |
| 92 |
-of these architectures. |
| 93 |
-</p> |
| 94 |
- |
| 95 |
-</body> |
| 96 |
-</section> |
| 97 |
- |
| 98 |
-<section> |
| 99 |
-<title>Upgrading ebuilds</title> |
| 100 |
-<body> |
| 101 |
- |
| 102 |
-<p> |
| 103 |
-New ebuilds should rarely go in with "<c>arch</c>" keywords and even if they do |
| 104 |
-not, the package <e>must</e> be tested on any architectures listed in the |
| 105 |
-<c>KEYWORDS</c> variable of the new ebuild. |
| 106 |
-</p> |
| 107 |
- |
| 108 |
-<p> |
| 109 |
-Exceptions to the no "<c>arch</c>" rule are major bug fixes, or |
| 110 |
-security fixes. If the previous version of the ebuild |
| 111 |
-contains <c>KEYWORDS</c> which you cannot test for, you should |
| 112 |
-downgrade them: turn any "<c>arch</c>" keyword to "<c>~arch</c>". If you |
| 113 |
-think that your package may not work at all even on "<c>~arch</c>" |
| 114 |
-then it is best to leave the keyword out and request testing from the |
| 115 |
-relevant team: if you are to do this, you must file a bug to the team |
| 116 |
-in question. |
| 117 |
-</p> |
| 118 |
- |
| 119 |
-<p> |
| 120 |
-If a new version introduces new dependencies which are not available |
| 121 |
-on some architectures, then you should file a bug or ask on IRC before |
| 122 |
-you upgrade the package. If you really need to get the ebuild added in |
| 123 |
-a hurry, for example, for a security fix, then you should drop |
| 124 |
-any <c>KEYWORDS</c> which are causing problems and CC the relevant |
| 125 |
-architectures on the bug <d/> you should file a new bug to the |
| 126 |
-architecture in question regarding this if no bug is already |
| 127 |
-available. |
| 128 |
-</p> |
| 129 |
- |
| 130 |
-<p> |
| 131 |
-If there are no new dependencies, do not remove keywords if your |
| 132 |
-commit fails with repoman <d/> please try a full <c>git pull</c> and if |
| 133 |
-you still have problems, then commit with <c>repoman -I</c> and file a |
| 134 |
-bug to the broken architecture, noting it in your git commit message. |
| 135 |
-</p> |
| 136 |
- |
| 137 |
-<warning> |
| 138 |
-When committing, make sure that you reference any bugs in the |
| 139 |
-commit message. Failing to do so is considered |
| 140 |
-to be in very poor taste and may result in disciplinary action. |
| 141 |
-</warning> |
| 142 |
- |
| 143 |
-</body> |
| 144 |
-</section> |
| 145 |
-</chapter> |
| 146 |
-</guide> |
| 147 |
|
| 148 |
diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml |
| 149 |
index 6c8d562..3576fbc 100644 |
| 150 |
--- a/ebuild-maintenance/text.xml |
| 151 |
+++ b/ebuild-maintenance/text.xml |
| 152 |
@@ -25,5 +25,4 @@ familiar with. |
| 153 |
<include href="package-moves/"/> |
| 154 |
<include href="collisions/"/> |
| 155 |
<include href="removal/"/> |
| 156 |
-<include href="stabilization/"/> |
| 157 |
</guide> |
| 158 |
|
| 159 |
diff --git a/keywording/text.xml b/keywording/text.xml |
| 160 |
index 4897186..3942138 100644 |
| 161 |
--- a/keywording/text.xml |
| 162 |
+++ b/keywording/text.xml |
| 163 |
@@ -1,7 +1,7 @@ |
| 164 |
<?xml version="1.0"?> |
| 165 |
<guide self="keywording/"> |
| 166 |
<chapter> |
| 167 |
-<title>Keywording</title> |
| 168 |
+<title>Keywording and Stabilization</title> |
| 169 |
<body> |
| 170 |
|
| 171 |
<note> |
| 172 |
@@ -204,15 +204,32 @@ stable tree getting broken this way. |
| 173 |
</p> |
| 174 |
|
| 175 |
<p> |
| 176 |
-Sometimes you may need to remove a keyword because of new unresolved |
| 177 |
-dependencies. If you do this, you <b>must</b> file a bug notifying the relevant |
| 178 |
-arch teams. |
| 179 |
+This also applies to revision bumps, not just to upstream version changes. |
| 180 |
</p> |
| 181 |
|
| 182 |
<p> |
| 183 |
-This also applies to revision bumps, not just to upstream version changes. |
| 184 |
+If a new version introduces new dependencies which are not available on some |
| 185 |
+architectures, then you should file a bug or ask on IRC before you upgrade the |
| 186 |
+ebuild. If you really need to get the ebuild added in a hurry, for example, |
| 187 |
+for a security fix, then you should drop any <c>KEYWORDS</c> which are causing |
| 188 |
+problems and CC the relevant architectures on the bug <d/> you <b>must</b> file |
| 189 |
+a new bug to the architecture in question regarding this if no bug is already |
| 190 |
+available. |
| 191 |
+</p> |
| 192 |
+ |
| 193 |
+<p> |
| 194 |
+If there are no new dependencies, do not remove keywords if your commit fails |
| 195 |
+with repoman <d/> please try a full <c>git pull</c> and if you still have |
| 196 |
+problems, then commit with <c>repoman -I</c> and file a bug to the broken |
| 197 |
+architecture, noting it in your git commit message. |
| 198 |
</p> |
| 199 |
|
| 200 |
+<important> |
| 201 |
+When committing, make sure that you reference any bugs in the commit message. |
| 202 |
+See <uri link="::ebuild-maintenance/git/#Git Commit Message Format"/> for how |
| 203 |
+to do this. |
| 204 |
+</important> |
| 205 |
+ |
| 206 |
</body> |
| 207 |
</section> |
| 208 |
|
| 209 |
@@ -221,18 +238,25 @@ This also applies to revision bumps, not just to upstream version changes. |
| 210 |
<body> |
| 211 |
|
| 212 |
<p> |
| 213 |
-Moving an ebuild from <c>~arch</c> to <c>arch</c> is done only by the relevant arch teams. |
| 214 |
-If you have access to non-x86 hardware but are not on the arch teams, you may wish |
| 215 |
-to make individual arrangements <d /> the arch teams are happy for help, so long as |
| 216 |
-they know what is going on. Please note that <c>x86</c> is now no longer an exception |
| 217 |
-and stabilisation must be done through the <c>x86</c> arch team unless you have |
| 218 |
-individual arrangements <d /> see |
| 219 |
-<uri link="https://www.gentoo.org/glep/glep-0040.html">GLEP 40</uri> |
| 220 |
-for further details. |
| 221 |
+Stabilization, i.e., moving an ebuild from <c>~arch</c> to <c>arch</c>, is done |
| 222 |
+by the relevant architecture teams. If you have access to exotic hardware but |
| 223 |
+are not on the arch teams, you may wish to make individual arrangements <d/> |
| 224 |
+the arch teams are happy for help, so long as they know what is going on. |
| 225 |
</p> |
| 226 |
|
| 227 |
<p> |
| 228 |
-For an ebuild to move to stable, the following guidelines must be met: |
| 229 |
+In order to request stabilization of an ebuild, file a bug to the package's |
| 230 |
+maintainer (which may be yourself), and list all secondary maintainers |
| 231 |
+in the bug's CC. When the maintainers consider the ebuild to be ready for |
| 232 |
+stabilization, they will add the relevant architecture teams to the CC list. |
| 233 |
+That way teams can remove themselves from the list when they are done, giving |
| 234 |
+a clear indication of which teams still have to stabilize a package. |
| 235 |
+</p> |
| 236 |
+ |
| 237 |
+<p> |
| 238 |
+For an ebuild to move to stable, the following guidelines must be met |
| 239 |
+(see <uri link="https://www.gentoo.org/glep/glep-0040.html">GLEP 40</uri> |
| 240 |
+for further details): |
| 241 |
</p> |
| 242 |
|
| 243 |
<ul> |
| 244 |
@@ -267,6 +291,37 @@ Vulnerability Treatment Policy</uri> |
| 245 |
|
| 246 |
</body> |
| 247 |
|
| 248 |
+<subsection> |
| 249 |
+<title>Stabilization rules</title> |
| 250 |
+<body> |
| 251 |
+ |
| 252 |
+<p> |
| 253 |
+SPARC: You must have prior permission from the arch lead. Usually we expect |
| 254 |
+you to be on the sparc alias for QA reasons, although other arrangements |
| 255 |
+can be made if you will only be working with a small group of packages. |
| 256 |
+</p> |
| 257 |
+ |
| 258 |
+<p> |
| 259 |
+ALPHA: Maintainers may keyword their own packages but are reminded to inform |
| 260 |
+the Alpha team if they can help out with testing and keywording packages so |
| 261 |
+the team can keep an eye out for possible keywording mistakes. |
| 262 |
+</p> |
| 263 |
+ |
| 264 |
+<p> |
| 265 |
+Exotic architectures (like hppa, ia64, ppc*, sparc) are short on manpower, |
| 266 |
+so it's best if you avoid opening bugs for stabilization of new packages |
| 267 |
+for them, unless it is absolutely necessary (e.g., a reverse dependency |
| 268 |
+for your package). |
| 269 |
+</p> |
| 270 |
+ |
| 271 |
+<p> |
| 272 |
+Some architectures (like mips, riscv) do not maintain a stable keyword. |
| 273 |
+So packages are not to be marked stable for one of these architectures. |
| 274 |
+</p> |
| 275 |
+ |
| 276 |
+</body> |
| 277 |
+</subsection> |
| 278 |
+ |
| 279 |
<subsection> |
| 280 |
<title>Simultaneous stabilization on all architectures</title> |
| 281 |
<body> |
Archives