summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'ebuild-writing')
-rw-r--r--ebuild-writing/functions/src_test/sample-sample.ebuild2
-rw-r--r--ebuild-writing/misc-files/changelog/text.rst40
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
nickname).
+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
+messages:
+
+* **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 : ..