| 1 |
commit: 39f82639c14734efb1a8638952e17984b38a0023 |
| 2 |
Author: Ulrich Müller <ulm <AT> gentoo <DOT> org> |
| 3 |
AuthorDate: Thu Jan 23 13:10:50 2020 +0000 |
| 4 |
Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org> |
| 5 |
CommitDate: Thu Jan 23 13:10:50 2020 +0000 |
| 6 |
URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=39f82639 |
| 7 |
|
| 8 |
keywording: Follow the terminology defined at start of the section. |
| 9 |
|
| 10 |
Closes: https://bugs.gentoo.org/567312 |
| 11 |
Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org> |
| 12 |
|
| 13 |
keywording/text.xml | 21 +++++++++++---------- |
| 14 |
1 file changed, 11 insertions(+), 10 deletions(-) |
| 15 |
|
| 16 |
diff --git a/keywording/text.xml b/keywording/text.xml |
| 17 |
index 6b2d19c..4897186 100644 |
| 18 |
--- a/keywording/text.xml |
| 19 |
+++ b/keywording/text.xml |
| 20 |
@@ -221,7 +221,7 @@ This also applies to revision bumps, not just to upstream version changes. |
| 21 |
<body> |
| 22 |
|
| 23 |
<p> |
| 24 |
-Moving a package from <c>~arch</c> to <c>arch</c> is done only by the relevant arch teams. |
| 25 |
+Moving an ebuild from <c>~arch</c> to <c>arch</c> is done only by the relevant arch teams. |
| 26 |
If you have access to non-x86 hardware but are not on the arch teams, you may wish |
| 27 |
to make individual arrangements <d /> the arch teams are happy for help, so long as |
| 28 |
they know what is going on. Please note that <c>x86</c> is now no longer an exception |
| 29 |
@@ -232,25 +232,26 @@ for further details. |
| 30 |
</p> |
| 31 |
|
| 32 |
<p> |
| 33 |
-For a package to move to stable, the following guidelines must be met: |
| 34 |
+For an ebuild to move to stable, the following guidelines must be met: |
| 35 |
</p> |
| 36 |
|
| 37 |
<ul> |
| 38 |
<li> |
| 39 |
- The package has spent a reasonable amount of time in <c>~arch</c> first. Thirty |
| 40 |
- days is the usual figure, although this is clearly only a guideline. For |
| 41 |
- critical packages, a much longer duration is expected. For small packages |
| 42 |
- which have only minor changes between versions, a shorter period is sometimes |
| 43 |
- appropriate. |
| 44 |
+ The ebuild has spent a reasonable amount of time in <c>~arch</c> first. |
| 45 |
+ Thirty days is the usual figure, although this is clearly only a guideline. |
| 46 |
+ For critical packages, a much longer duration is expected. For small |
| 47 |
+ packages that have only minor changes between versions, a shorter period is |
| 48 |
+ sometimes appropriate. |
| 49 |
</li> |
| 50 |
<li> |
| 51 |
- The package must not have any non-<c>arch</c> dependencies. |
| 52 |
+ The ebuild must not have any non-<c>arch</c> dependencies. |
| 53 |
</li> |
| 54 |
<li> |
| 55 |
- The package must not have any severe outstanding bugs or issues. |
| 56 |
+ The package version (and the ebuild) must not have any severe outstanding |
| 57 |
+ bugs or issues. |
| 58 |
</li> |
| 59 |
<li> |
| 60 |
- The package must be widely tested. |
| 61 |
+ The package version must be widely tested. |
| 62 |
</li> |
| 63 |
<li> |
| 64 |
If the package is a library, it should be known not to break any package which |
Archives