diff options
| author | Mark Wielaard <mjw@redhat.com> | 2009-02-20 14:56:38 +0100 |
|---|---|---|
| committer | Mark Wielaard <mjw@redhat.com> | 2009-02-20 14:56:38 +0100 |
| commit | 02615365a92ca2570c1f96abc8a97674aa2ccae1 (patch) | |
| tree | ebedfd91a0f6d299b39e84295e091e12c0767dc8 /HACKING | |
| parent | c3bad3042df505a3470f1e20b09822a9df1d4761 (diff) | |
| parent | adc67597f327cd43d58b1d0cb740dab14a75a058 (diff) | |
| download | systemtap-steved-02615365a92ca2570c1f96abc8a97674aa2ccae1.tar.gz systemtap-steved-02615365a92ca2570c1f96abc8a97674aa2ccae1.tar.xz systemtap-steved-02615365a92ca2570c1f96abc8a97674aa2ccae1.zip | |
Merge branch 'master' into pr6866
Conflicts:
ChangeLog: Removed
runtime/ChangeLog: Removed
runtime/sym.c: Merged
runtime/task_finder.c: Merged
tapset/ChangeLog: Removed
testsuite/ChangeLog: Removed
Diffstat (limited to 'HACKING')
| -rw-r--r-- | HACKING | 30 |
1 files changed, 19 insertions, 11 deletions
@@ -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 |