]>
Commit | Line | Data |
---|---|---|
5b25658f | 1 | This text describes contribution procedures to systemtap. Please read |
bab2d8d0 | 2 | and understand them before jumping in. Discussions take place on |
5b25658f FCE |
3 | the <systemtap@sources.redhat.com> mailing list. |
4 | ||
5 | - general | |
6 | ||
7 | Submissions should be in an easy-to-read diff/patch form, unless | |
8 | this is inappropriate due to size, relevance, or fraction of novel | |
9 | content. They should be accompanied by an explanation, and | |
10 | ChangeLog entries. The relevant test suites should be run before | |
11 | and after your changes, and regressions avoided, explained, or | |
12 | corrected. | |
13 | ||
14 | Established contributors may be considered for direct CVS write | |
15 | access. Other contributors should simply pack up the goods into a | |
16 | plain text email message to the mailing list. | |
17 | ||
18 | - obvious changes | |
19 | ||
20 | Trivial, obvious patches may be posted or committed without other | |
21 | formalities. | |
22 | ||
23 | - copyright | |
24 | ||
25 | You must designate the appropriate copyright holder for your | |
26 | contribution. If not already there, this name should be added by | |
27 | your patch to the copyright header in the affected files. The | |
28 | copyright holder is assumed to agree with the general licensing | |
29 | terms (GPLv2+). | |
30 | ||
31 | - coding style | |
32 | ||
33 | Abide by the general formatting of the code you are modifying. The | |
34 | code base generally follows the GNU standards. ChangeLog entries | |
35 | are used for nontrivial changes to source or documentation files. | |
36 | Some subdirectories have ChangeLog files of their own, so make sure | |
37 | you find the correct ones to prepend. | |
38 | ||
39 | - test suites | |
40 | ||
41 | As far as practicable, changes should be accompanied by test cases | |
1dca31ba FCE |
42 | to prevent future regressions. Tests should be run on at least |
43 | x86, and ideally also on some 64-bit platform. | |
5b25658f FCE |
44 | |
45 | Tests that don't require probe execution should go into new or | |
46 | modified files under /src/testsuite/, a simple automake-flavoured | |
47 | bucket. Subdirectories exist for testing only up to pass 1 | |
48 | (parseok/parseko), pass 2 (semok/semko), pass 3 (transok,transko), | |
49 | and pass 4 (buildok/buildko). The "ko" tests are for expected | |
50 | (deliberate) errors. | |
51 | ||
52 | Tests that execute probes (pass 5) go under /tests/testsuite/, a | |
53 | dejagnu-based bucket that will require root access to run. | |
54 | ||
55 | - translator | |
56 | ||
57 | Translator changes can easily invalidate tapsets and user script | |
58 | code. One must tread carefully and run regression tests rigorously. | |
59 | Both positive and negative polarity (expect-pass / expect-fail) test | |
60 | cases may need to be written to assert a bug fix. Script language | |
61 | changes should be documented in the stap.1 man page. | |
62 | ||
63 | - tapsets | |
64 | ||
65 | Tapset script files should demonstrate effective economy, and avoid | |
66 | conflicts with user and other tapset code. | |
67 | ||
68 | It may be necessary to prefix symbols with the tapset name to ensure | |
dbbb2cec | 69 | systemtap-wide uniqueness. All "external interfaces" expected to be |
5b25658f FCE |
70 | used by user scripts (or perhaps other tapsets) should be documented |
71 | in stapfuncs.5, stapprobes.5. Internal function, variable, probe | |
72 | identifiers should be prefixed with "_" for extra uniqueness, and | |
73 | not documented in the man pages. | |
74 | ||
a9a29deb FCE |
75 | Tapsets should come with a tests cases that provide good test coverage. |
76 | Every alias definition should be tested for pass-2 correctness. Every | |
77 | embedded-C routine should be tested for pass-4 buildability and ideally | |
78 | pass-5 correctness. The platforms/architectures against which the tapset | |
79 | was tested should be published, and ideally asserted by code. | |
80 | ||
81 | Embedded-C code should avoid making references to the runtime or | |
82 | other code possibly generated by the translator. | |
5b25658f FCE |
83 | |
84 | - runtime | |
85 | ||
86 | Changes to the runtime can cause problems on different architectures | |
87 | or kernel versions. Luckily, many code mistakes show up easily in | |
88 | the pass-4 tests. [hunt: if appropriate, fill in information for | |
89 | runtime self-testing code] | |
90 | ||
91 | - meta | |
92 | ||
93 | Proposed changes to these guidelines should be discussed on the | |
94 | mailing list. |