* [gentoo-commits] proj/devmanual:master commit in: keywording/, ebuild-maintenance/stabilization/, ebuild-maintenance/
@ 2020-01-25 6:02 Ulrich Müller
0 siblings, 0 replies; only message in thread
From: Ulrich Müller @ 2020-01-25 6:02 UTC (permalink / raw
To: gentoo-commits
commit: 449da7f72272a7f3c4b5c5a2761151fc553d7338
Author: Ulrich Müller <ulm <AT> gentoo <DOT> org>
AuthorDate: Thu Jan 23 16:54:18 2020 +0000
Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org>
CommitDate: Sat Jan 25 05:53:21 2020 +0000
URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=449da7f7
keywording: Include sections about stabilization.
Remove the ebuild-maintenance/stabilization section (which resulted
from the split of ebuild-maintenance/maintenance-tasks), and include
it in keywording. Delete duplicate and outdated information.
Closes: https://bugs.gentoo.org/648316
Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org>
ebuild-maintenance/stabilization/text.xml | 119 ------------------------------
ebuild-maintenance/text.xml | 1 -
keywording/text.xml | 83 +++++++++++++++++----
3 files changed, 69 insertions(+), 134 deletions(-)
diff --git a/ebuild-maintenance/stabilization/text.xml b/ebuild-maintenance/stabilization/text.xml
deleted file mode 100644
index b67c2b5..0000000
--- a/ebuild-maintenance/stabilization/text.xml
+++ /dev/null
@@ -1,119 +0,0 @@
-<?xml version="1.0"?>
-<guide self="ebuild-maintenance/stabilization/">
-<chapter>
-<title>Stabilizing and Upgrading Ebuilds</title>
-
-<section>
-<title>Stabilizing ebuilds</title>
-<body>
-
-<p>
-Only architecture maintainers for a given architecture should mark packages as
-stable on that architecture. The maintainer of the package should always be
-contacted just in case there are reasons not to do so. The exception to this
-is if you are part of an architecture team, in which case you may mark the
-package stable for that architecture. If you are not part of an architecture
-team, you should consult the guidelines below; if the architecture you are
-looking for is not listed then please consult the relevant lead.
-</p>
-
-<p>
-You should <e>never</e> stabilize packages on architectures for which you
-cannot test and instead you should file a bug to the relevant architecture
-team, such as <c>sparc@gentoo.org</c> asking them to stabilize the ebuild.
-Alternatively, you may be able to find Gentoo developers on IRC who could help
-you with your request.
-</p>
-
-<p>
-It is best to not use <c>arch-maintainers@gentoo.org</c>, adding architecture
-teams onto a bug's CC list individually instead. That way teams can remove
-themselves from the list when they are done, giving a clear indication
-of which teams still have to stabilize a package.
-</p>
-
-</body>
-</section>
-
-<section>
-<title>Stabilization rules</title>
-<body>
-
-<p>
-SPARC: You must have prior permission from the arch lead. Usually we expect
-you to be on the sparc alias for QA reasons, although other arrangements
-can be made if you will only be working with a small group of packages.
-</p>
-
-<p>
-ALPHA: Maintainers may keyword their own packages but are reminded to inform
-the Alpha team if they can help out with testing and keywording packages so
-the team can keep an eye out for possible keywording mistakes.
-</p>
-
-<p>
-Exotic architectures (like alpha, ia64, sparc, hppa, ppc*) are short
-on manpower, so it's best if you avoid opening stabilization bugs for
-them unless it is absolutely necessary (eg, a reverse dependency for
-your package). More about keywording policies can be found in the
-<uri link="::keywording">keywording</uri> section.
-</p>
-
-<p>
-Some architectures (like m68k, mips, s390, sh) do not maintain a
-stable keyword. So there is no use in marking a package stable for one
-of these architectures.
-</p>
-
-</body>
-</section>
-
-<section>
-<title>Upgrading ebuilds</title>
-<body>
-
-<p>
-New ebuilds should rarely go in with "<c>arch</c>" keywords and even if they do
-not, the package <e>must</e> be tested on any architectures listed in the
-<c>KEYWORDS</c> variable of the new ebuild.
-</p>
-
-<p>
-Exceptions to the no "<c>arch</c>" rule are major bug fixes, or
-security fixes. If the previous version of the ebuild
-contains <c>KEYWORDS</c> which you cannot test for, you should
-downgrade them: turn any "<c>arch</c>" keyword to "<c>~arch</c>". If you
-think that your package may not work at all even on "<c>~arch</c>"
-then it is best to leave the keyword out and request testing from the
-relevant team: if you are to do this, you must file a bug to the team
-in question.
-</p>
-
-<p>
-If a new version introduces new dependencies which are not available
-on some architectures, then you should file a bug or ask on IRC before
-you upgrade the package. If you really need to get the ebuild added in
-a hurry, for example, for a security fix, then you should drop
-any <c>KEYWORDS</c> which are causing problems and CC the relevant
-architectures on the bug <d/> you should file a new bug to the
-architecture in question regarding this if no bug is already
-available.
-</p>
-
-<p>
-If there are no new dependencies, do not remove keywords if your
-commit fails with repoman <d/> please try a full <c>git pull</c> and if
-you still have problems, then commit with <c>repoman -I</c> and file a
-bug to the broken architecture, noting it in your git commit message.
-</p>
-
-<warning>
-When committing, make sure that you reference any bugs in the
-commit message. Failing to do so is considered
-to be in very poor taste and may result in disciplinary action.
-</warning>
-
-</body>
-</section>
-</chapter>
-</guide>
diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml
index 6c8d562..3576fbc 100644
--- a/ebuild-maintenance/text.xml
+++ b/ebuild-maintenance/text.xml
@@ -25,5 +25,4 @@ familiar with.
<include href="package-moves/"/>
<include href="collisions/"/>
<include href="removal/"/>
-<include href="stabilization/"/>
</guide>
diff --git a/keywording/text.xml b/keywording/text.xml
index 4897186..3942138 100644
--- a/keywording/text.xml
+++ b/keywording/text.xml
@@ -1,7 +1,7 @@
<?xml version="1.0"?>
<guide self="keywording/">
<chapter>
-<title>Keywording</title>
+<title>Keywording and Stabilization</title>
<body>
<note>
@@ -204,15 +204,32 @@ stable tree getting broken this way.
</p>
<p>
-Sometimes you may need to remove a keyword because of new unresolved
-dependencies. If you do this, you <b>must</b> file a bug notifying the relevant
-arch teams.
+This also applies to revision bumps, not just to upstream version changes.
</p>
<p>
-This also applies to revision bumps, not just to upstream version changes.
+If a new version introduces new dependencies which are not available on some
+architectures, then you should file a bug or ask on IRC before you upgrade the
+ebuild. If you really need to get the ebuild added in a hurry, for example,
+for a security fix, then you should drop any <c>KEYWORDS</c> which are causing
+problems and CC the relevant architectures on the bug <d/> you <b>must</b> file
+a new bug to the architecture in question regarding this if no bug is already
+available.
+</p>
+
+<p>
+If there are no new dependencies, do not remove keywords if your commit fails
+with repoman <d/> please try a full <c>git pull</c> and if you still have
+problems, then commit with <c>repoman -I</c> and file a bug to the broken
+architecture, noting it in your git commit message.
</p>
+<important>
+When committing, make sure that you reference any bugs in the commit message.
+See <uri link="::ebuild-maintenance/git/#Git Commit Message Format"/> for how
+to do this.
+</important>
+
</body>
</section>
@@ -221,18 +238,25 @@ This also applies to revision bumps, not just to upstream version changes.
<body>
<p>
-Moving an ebuild from <c>~arch</c> to <c>arch</c> is done only by the relevant arch teams.
-If you have access to non-x86 hardware but are not on the arch teams, you may wish
-to make individual arrangements <d /> the arch teams are happy for help, so long as
-they know what is going on. Please note that <c>x86</c> is now no longer an exception
-and stabilisation must be done through the <c>x86</c> arch team unless you have
-individual arrangements <d /> see
-<uri link="https://www.gentoo.org/glep/glep-0040.html">GLEP 40</uri>
-for further details.
+Stabilization, i.e., moving an ebuild from <c>~arch</c> to <c>arch</c>, 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 individual arrangements <d/>
+the arch teams are happy for help, so long as they know what is going on.
</p>
<p>
-For an ebuild to move to stable, the following guidelines must be met:
+In order to request stabilization of an ebuild, file a bug to the package's
+maintainer (which may be yourself), and list all secondary maintainers
+in the bug's CC. When the maintainers consider the ebuild to be ready for
+stabilization, they will add the relevant architecture teams to the CC list.
+That way teams can remove themselves from the list when they are done, giving
+a clear indication of which teams still have to stabilize a package.
+</p>
+
+<p>
+For an ebuild to move to stable, the following guidelines must be met
+(see <uri link="https://www.gentoo.org/glep/glep-0040.html">GLEP 40</uri>
+for further details):
</p>
<ul>
@@ -267,6 +291,37 @@ Vulnerability Treatment Policy</uri>
</body>
+<subsection>
+<title>Stabilization rules</title>
+<body>
+
+<p>
+SPARC: You must have prior permission from the arch lead. Usually we expect
+you to be on the sparc alias for QA reasons, although other arrangements
+can be made if you will only be working with a small group of packages.
+</p>
+
+<p>
+ALPHA: Maintainers may keyword their own packages but are reminded to inform
+the Alpha team if they can help out with testing and keywording packages so
+the team can keep an eye out for possible keywording mistakes.
+</p>
+
+<p>
+Exotic architectures (like hppa, ia64, ppc*, sparc) are short on manpower,
+so it's best if you avoid opening bugs for stabilization of new packages
+for them, unless it is absolutely necessary (e.g., a reverse dependency
+for your package).
+</p>
+
+<p>
+Some architectures (like mips, riscv) do not maintain a stable keyword.
+So packages are not to be marked stable for one of these architectures.
+</p>
+
+</body>
+</subsection>
+
<subsection>
<title>Simultaneous stabilization on all architectures</title>
<body>
^ permalink raw reply related [flat|nested] only message in thread
only message in thread, other threads:[~2020-01-25 6:02 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-25 6:02 [gentoo-commits] proj/devmanual:master commit in: keywording/, ebuild-maintenance/stabilization/, ebuild-maintenance/ Ulrich Müller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox