* [gentoo-commits] proj/devmanual:master commit in: ebuild-maintenance/, ebuild-maintenance/maintenance-tasks/, ...
@ 2020-01-23 7:49 Ulrich Müller
0 siblings, 0 replies; 2+ messages in thread
From: Ulrich Müller @ 2020-01-23 7:49 UTC (permalink / raw
To: gentoo-commits
commit: 450692994d68bed141e324284ac9be671f8c84bf
Author: Ulrich Müller <ulm <AT> gentoo <DOT> org>
AuthorDate: Tue Jan 21 11:02:00 2020 +0000
Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org>
CommitDate: Thu Jan 23 07:48:07 2020 +0000
URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=45069299
ebuild-maintenance/maintenance-tasks: Drop "Homepage unavailable" section.
This isn't really a maintenance task. Also, we already mention this
twice elsewhere, namely in ebuild-writing/variables and in
ebuild-writing/common-mistakes. Update and fix link in the latter.
Move the introductory paragraph to the parent document, and remove
the chapter which has become empty.
Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org>
ebuild-maintenance/maintenance-tasks/text.xml | 28 ---------------------------
ebuild-maintenance/text.xml | 7 +++++--
ebuild-writing/common-mistakes/text.xml | 12 ++++++------
3 files changed, 11 insertions(+), 36 deletions(-)
diff --git a/ebuild-maintenance/maintenance-tasks/text.xml b/ebuild-maintenance/maintenance-tasks/text.xml
deleted file mode 100644
index ccdefe9..0000000
--- a/ebuild-maintenance/maintenance-tasks/text.xml
+++ /dev/null
@@ -1,28 +0,0 @@
-<?xml version="1.0"?>
-<guide self="ebuild-maintenance/maintenance-tasks/">
-<chapter>
-<title>Maintenance Tasks</title>
-
-<body>
-<p>
-This guide aims to explain common everyday ebuild maintenance
-routines, as well as other rarer maintenance routines which
-developers may not be familiar with.
-</p>
-</body>
-
-<section>
-<title>Homepage unavailable</title>
-<body>
-
-<p>
-If the <c>HOMEPAGE</c> of your package seems to be unavailable or it
-never existed at all, please set the HOMEPAGE variable in every ebuild
-to <uri link="https://wiki.gentoo.org/wiki/No_homepage">
-https://wiki.gentoo.org/wiki/No_homepage</uri>
-</p>
-
-</body>
-</section>
-</chapter>
-</guide>
diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml
index 1917b07..a9f295c 100644
--- a/ebuild-maintenance/text.xml
+++ b/ebuild-maintenance/text.xml
@@ -2,11 +2,14 @@
<guide self="ebuild-maintenance/">
<chapter>
<title>Ebuild Maintenance</title>
-
<body>
+
<p>
-This section covers various tasks related to working with ebuilds.
+This section aims to explain common everyday ebuild maintenance routines,
+as well as other rarer maintenance routines which developers may not be
+familiar with.
</p>
+
</body>
<section>
diff --git a/ebuild-writing/common-mistakes/text.xml b/ebuild-writing/common-mistakes/text.xml
index 2127b3f..ff9b377 100644
--- a/ebuild-writing/common-mistakes/text.xml
+++ b/ebuild-writing/common-mistakes/text.xml
@@ -363,12 +363,12 @@ SLOT="0"
<body>
<p>
-Please check if the HOMEPAGE variable is right and leads users to the right
-page if they want to find out more about the package. And make sure the
-DESCRIPTION is not overly long. Good descriptions will describe the main
-function of the package in a sentence. Set HOMEPAGE to
-<uri link="::ebuild-maintenance/maintenance-tasks#Homepage unavailable">
-No_homepage wiki page</uri>, if there is none.
+Please check if the <c>HOMEPAGE</c> variable is right and leads users to the
+right page if they want to find out more about the package. And make sure
+the <c>DESCRIPTION</c> is not overly long. Good descriptions will describe
+the main function of the package in a sentence. If no homepage for the package
+is available, set the <c>HOMEPAGE</c> variable to
+<c>https://wiki.gentoo.org/wiki/No_homepage</c>.
</p>
</body>
^ permalink raw reply related [flat|nested] 2+ messages in thread
* [gentoo-commits] proj/devmanual:master commit in: ebuild-maintenance/, ebuild-maintenance/maintenance-tasks/, ...
@ 2020-01-23 7:49 Ulrich Müller
0 siblings, 0 replies; 2+ messages in thread
From: Ulrich Müller @ 2020-01-23 7:49 UTC (permalink / raw
To: gentoo-commits
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>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>
-
<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>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 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>
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-01-23 7:49 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-23 7:49 [gentoo-commits] proj/devmanual:master commit in: ebuild-maintenance/, ebuild-maintenance/maintenance-tasks/, Ulrich Müller
-- strict thread matches above, loose matches on Subject: below --
2020-01-23 7:49 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