diff options
authorUlrich Müller <ulm@gentoo.org>2005-08-09 01:08:48 +0000
committerUlrich Müller <ulm@gentoo.org>2020-01-09 23:50:53 +0100
commit1f5d65e83b935ba1c232215f827b2326092d1b1d (patch)
parentreStructuredText source of the devmanual (diff)
Update from 2005-08-09historical
Taken from ~genstef/public_html/files/devmanual.tar.bz2 on dev.gentoo.org, which internally has plasmaroo/public_html/devmanual/ as prefix for all files. Timestamp of newest file: 2005-08-09 01:08:48 +0000 Signed-off-by: Ulrich Müller <ulm@gentoo.org>
2 files changed, 41 insertions, 1 deletions
diff --git a/ebuild-writing/functions/src_test/sample-sample.ebuild b/ebuild-writing/functions/src_test/sample-sample.ebuild
index b22bfa4..4c301ba 100644
--- a/ebuild-writing/functions/src_test/sample-sample.ebuild
+++ b/ebuild-writing/functions/src_test/sample-sample.ebuild
@@ -1,6 +1,6 @@
-src_compile() {
+src_test() {
cd ${S}/src/testdir
# Test 49 won't work inside a portage environment
diff --git a/ebuild-writing/misc-files/changelog/text.rst b/ebuild-writing/misc-files/changelog/text.rst
index c54eff8..0e373ee 100644
--- a/ebuild-writing/misc-files/changelog/text.rst
+++ b/ebuild-writing/misc-files/changelog/text.rst
@@ -16,8 +16,48 @@ credit the user with their full name and email address (or whatever they use to
identify themselves on bugzilla -- some users prefer to be known only by a
+If you are changing keywords, make sure you clearly state what keywords you add
+or remove. "Marked stable" is a nuisance for architecture teams, even if there
+was only one keyword in the ebuild at the time. "Stable on all archs" isn't
+generally any better (and should you really be stabling on all archs?) -- do
+you mean "all", or "all the ones that are currently keyworded"? A list like
+"x86 sparc mips" is much more useful.
A typical ``ChangeLog`` snippet might look like the following:
.. CODESAMPLE changelog
+Writing correct ChangeLog messages
+.. Note:: It is *very* important that your ``cvs commit`` messages are
+ also informative to aid the QA team or architecture teams as well
+ as other developers if they are trying to troubleshoot issues which
+ are known to not have occured in previous versions of ebuilds, for
+ example. If your ChangeLog message is concise there is usually
+ nothing wrong with using it as the ``cvs commit`` message.
+Your message should explain what specifically you changed and, if
+relevant, why. You don't need to write an essay or even a complete
+sentence (ChangeLog messages, however, *are* required to be in
+'proper' English so no ``fixed that bug, kthx Bob`` messages -- please
+do use punctuation), so long as it is easily understandable and
+(preferably) greppable. Examples, all of which are based upon real
+* **BAD**: Changed keywords
+* *GOOD*: Added ~x86 keyword
+* **BAD**: Stable
+* *GOOD*: Stable on x86, sparc, mips
+* **BAD**: Fix stuff
+* *GOOD*: Fix USE=foo logic error
+* **BAD**: .
+* *GOOD*: Purge old ebuilds
+* **BAD**: Who the fuck reads these anyway? (**Editor's note**: No, seriously, this is a genuine example. Do *not* do this...)
+* *GOOD*: Version bump to 0.5.1.
.. vim: set ft=glep tw=80 sw=4 et spell spelllang=en : ..