commit: 39f82639c14734efb1a8638952e17984b38a0023 Author: Ulrich Müller <ulm <AT> gentoo <DOT> org> AuthorDate: Thu Jan 23 13:10:50 2020 +0000 Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org> CommitDate: Thu Jan 23 13:10:50 2020 +0000 URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=39f82639
keywording: Follow the terminology defined at start of the section. Closes: https://bugs.gentoo.org/567312 Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org> keywording/text.xml | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/keywording/text.xml b/keywording/text.xml index 6b2d19c..4897186 100644 --- a/keywording/text.xml +++ b/keywording/text.xml @@ -221,7 +221,7 @@ This also applies to revision bumps, not just to upstream version changes. <body> <p> -Moving a package from <c>~arch</c> to <c>arch</c> is done only by the relevant arch teams. +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 @@ -232,25 +232,26 @@ for further details. </p> <p> -For a package to move to stable, the following guidelines must be met: +For an ebuild to move to stable, the following guidelines must be met: </p> <ul> <li> - The package has spent a reasonable amount of time in <c>~arch</c> first. Thirty - days is the usual figure, although this is clearly only a guideline. For - critical packages, a much longer duration is expected. For small packages - which have only minor changes between versions, a shorter period is sometimes - appropriate. + The ebuild has spent a reasonable amount of time in <c>~arch</c> first. + Thirty days is the usual figure, although this is clearly only a guideline. + For critical packages, a much longer duration is expected. For small + packages that have only minor changes between versions, a shorter period is + sometimes appropriate. </li> <li> - The package must not have any non-<c>arch</c> dependencies. + The ebuild must not have any non-<c>arch</c> dependencies. </li> <li> - The package must not have any severe outstanding bugs or issues. + The package version (and the ebuild) must not have any severe outstanding + bugs or issues. </li> <li> - The package must be widely tested. + The package version must be widely tested. </li> <li> If the package is a library, it should be known not to break any package which
