From 377f3fa917795a4f39fbf8f22b20b0385eee13c1 Mon Sep 17 00:00:00 2001 From: Josh Stone Date: Thu, 19 Feb 2009 20:00:31 -0800 Subject: 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. --- HACKING | 30 +++++++++++++++++++----------- tapset/DEVGUIDE | 9 +-------- 2 files changed, 20 insertions(+), 19 deletions(-) diff --git a/HACKING b/HACKING index 98c19e7f..5a1b86bf 100644 --- a/HACKING +++ b/HACKING @@ -6,10 +6,9 @@ the 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 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 62e1ecdd..e6bc3fb8 100644 --- 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 ------------------- -- cgit