Update guidelines for the ChangeLog-less world

Getting rid of ChangeLogs doesn't mean that we get a free ticket -- we
now need to be more diligent about providing meaningful commit messages.
I've updated the HACKING file with a first draft of new guidelines, but
we may still revise what we feel is appropriate detail in the logs.

I removed the ChangeLog section from the tapset/DEVGIDE entirely, and
also fixed the path where examples are stored.

diff --git a/HACKING b/HACKING
index 98c19e7f6db1e0c5c1a960e84e08e4dddf46d12e..5a1b86bfdd868211fc024b9123a00c1b03621633 100644 (file)
--- a/HACKING
+++ b/HACKING
@@ -6,10 +6,9 @@ the <systemtap@sources.redhat.com> mailing list.
 
   Submissions should be in an easy-to-read diff/patch form, unless
   this is inappropriate due to size, relevance, or fraction of novel
-  content.  They should be accompanied by an explanation, and
-  ChangeLog entries.  The relevant test suites should be run before
-  and after your changes, and regressions avoided, explained, or
-  corrected.
+  content.  They should be accompanied by an explanation.  The
+  relevant test suites should be run before and after your changes,
+  and regressions avoided, explained, or corrected.
 
   Established contributors may be considered for direct GIT write
   access.  Other contributors should simply pack up the goods into a
@@ -31,13 +30,22 @@ the <systemtap@sources.redhat.com> mailing list.
 - coding style
 
   Abide by the general formatting of the code you are modifying.  The
-  code base generally follows the GNU standards.  ChangeLog entries
-  are used for nontrivial changes to source or documentation files.
-  Some subdirectories have ChangeLog files of their own, so make sure
-  you find the correct ones to prepend.
-
-  In the git commit message, make the first line an brief summary of
-  the patch.  There is no need to transcribe the ChangeLog entries there.
+  code base generally follows the GNU standards in usermode code and
+  the Linux kernel standards in runtime code.
+
+- commit messages
+
+  In the git commit message, make the first line a brief (<=50 char)
+  summary of the patch, and leave the second line blank.  If you have
+  trouble coming up with a concise summary, consider whether your
+  patch might be better broken into smaller commits.
+
+  For trivial changes, the summary alone may be sufficient, but most
+  commits should include a paragraph or two giving more details about
+  what the change is and why it is needed.  Extra information like
+  bugzilla numbers and mailing-list discussion links are appreciated
+  as a supplement, but they are not a replacement for a real
+  description.
 
 - test suites
 

diff --git a/tapset/DEVGUIDE b/tapset/DEVGUIDE
index 62e1ecdd449f52c07d469f1573d0c7fbac32a5f9..e6bc3fb8bb644acd1db866736366e650aa0e54b5 100644 (file)
--- a/tapset/DEVGUIDE
+++ b/tapset/DEVGUIDE
@@ -231,14 +231,7 @@ most important, it validates that the tapset can actually be used for
 something useful.  If you can't write a script that uses the tapset in a
 meaningful way, perhaps you should rethink what the tapset provides.
 
-Example scripts are stored in src/examples in GIT.
-
-Change Logs
------------
-Update the appropriate ChangeLog files with a brief description of your
-additions and changes.  Note that the change description you enter during
-a "cvs commit" does not get added to the ChangeLog files.  You must edit
-the ChangeLog files directly and commit them as well.
+Example scripts are stored in testsuite/systemtap.examples/ in GIT.
 
 Embedded C & Safety
 -------------------