diff options
| author |   Ulrich Müller <ulm@gentoo.org> | 2020-01-23 17:54:18 +0100 |
|---|---|---|
| committer | Ulrich Müller <ulm@gentoo.org> | 2020-01-25 06:53:21 +0100 |
| commit | 449da7f72272a7f3c4b5c5a2761151fc553d7338 (patch) | |
| tree | 5f1a8f77e889a2a5f4d78514997df136dd5b3447 /ebuild-maintenance | |
| parent | ebuild-writing/users-and-groups: Use example ebuilds from tree. (diff) | |
| download | devmanual-449da7f72272a7f3c4b5c5a2761151fc553d7338.tar.gz devmanual-449da7f72272a7f3c4b5c5a2761151fc553d7338.tar.bz2 devmanual-449da7f72272a7f3c4b5c5a2761151fc553d7338.zip | |
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@gentoo.org>
Diffstat (limited to 'ebuild-maintenance')
| -rw-r--r-- | ebuild-maintenance/stabilization/text.xml | 119 | ||||
| -rw-r--r-- | ebuild-maintenance/text.xml | 1 |
2 files changed, 0 insertions, 120 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> |