commit: 94f6c54fc9638f347696a2f361b393959e02d0ee Author: Ulrich Müller <ulm <AT> gentoo <DOT> org> AuthorDate: Tue Jan 21 10:45:33 2020 +0000 Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org> CommitDate: Thu Jan 23 07:48:05 2020 +0000 URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=94f6c54f
ebuild-maintenance/stabilization: New chapter. Split off from ebuild-maintenance/maintenance-tasks. Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org> ebuild-maintenance/maintenance-tasks/text.xml | 111 ------------------------ ebuild-maintenance/stabilization/text.xml | 119 ++++++++++++++++++++++++++ ebuild-maintenance/text.xml | 1 + 3 files changed, 120 insertions(+), 111 deletions(-) diff --git a/ebuild-maintenance/maintenance-tasks/text.xml b/ebuild-maintenance/maintenance-tasks/text.xml index 972b7b3..f4e421a 100644 --- a/ebuild-maintenance/maintenance-tasks/text.xml +++ b/ebuild-maintenance/maintenance-tasks/text.xml @@ -11,117 +11,6 @@ developers may not be familiar with. </p> </body> -<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>[email protected]</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>[email protected]</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> - <section> <title>Removing ebuilds</title> <body> diff --git a/ebuild-maintenance/stabilization/text.xml b/ebuild-maintenance/stabilization/text.xml new file mode 100644 index 0000000..b67c2b5 --- /dev/null +++ b/ebuild-maintenance/stabilization/text.xml @@ -0,0 +1,119 @@ +<?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>[email protected]</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>[email protected]</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 58ac723..49a7fe1 100644 --- a/ebuild-maintenance/text.xml +++ b/ebuild-maintenance/text.xml @@ -20,5 +20,6 @@ This section covers various tasks related to working with ebuilds. <include href="new-ebuild/"/> <include href="git/"/> <include href="package-moves/"/> +<include href="stabilization/"/> <include href="maintenance-tasks/"/> </guide>
