Commit | Line | Data |
---|---|---|
93794bcc PP |
1 | # LTTng-tools contributor's guide |
2 | ||
3 | Being an open source project, the LTTng-tools project welcomes | |
4 | contributions from anyone. This guide walks you through the process | |
5 | of contributing a patch to LTTng-tools. | |
6 | ||
7 | ||
8 | ## Getting the source code | |
9 | ||
10 | The LTTng-tools project uses [Git](https://git-scm.com/) for version | |
11 | control. The upstream Git repository URL is: | |
12 | ||
13 | git://git.lttng.org/lttng-tools.git | |
14 | ||
15 | ||
16 | ## Coding standard | |
17 | ||
d17cc1f3 | 18 | See CodingStyle for guidelines style and design guidelines. |
93794bcc PP |
19 | |
20 | Although the LTTng-tools code base is primarily written in C, it does | |
21 | contain shell, Perl, and Python code as well. There is no official coding | |
22 | standard for these languages. However, using a style consistent with the | |
23 | rest of the code written in that language is strongly encouraged. | |
24 | ||
25 | ||
26 | ## Creating and sending a patch | |
27 | ||
8d82bb77 KS |
28 | LTTng-tools's development flow is primarily based on |
29 | [Gerrit Code Review](https://review.lttng.org), although we also accept | |
30 | e-mail based patch series on the | |
31 | [`lttng-dev` mailing list](https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev) | |
32 | and pull requests on our [GitHub mirror](https://github.com/lttng/lttng-tools). | |
33 | If you're going to create GitHub pull requests, make sure you still follow the | |
93794bcc PP |
34 | guidelines below. |
35 | ||
8d82bb77 KS |
36 | The mailing list is also used to share and comment on |
37 | <abbr title="Request for Comments">RFC</abbr>s and answer | |
93794bcc PP |
38 | user questions. |
39 | ||
8d82bb77 KS |
40 | Once your changes have been comitted to your local branch, you may use the |
41 | [git-review](https://opendev.org/opendev/git-review) plugin to submit them | |
42 | directly to [Gerrit](https://review.lttng.org) using the following command: | |
43 | ||
44 | git review | |
45 | ||
46 | Please note that you will need to create an account on [Gerrit](https://review.lttng.org) | |
47 | and add an SSH public key. | |
48 | ||
49 | For e-mail based patches you may use Git's | |
50 | [`format-patch`](https://git-scm.com/docs/git-format-patch) command | |
93794bcc PP |
51 | to generate a patch file. The following command line generates a |
52 | patch from the latest commit: | |
53 | ||
54 | git format-patch -N1 -s --subject-prefix="PATCH lttng-tools" | |
55 | ||
56 | The custom `PATCH lttng-tools` subject prefix is mandatory when | |
57 | submitting patches that apply to the LTTng-tools project. | |
58 | ||
59 | The patch's subject (the commit message's first line) should: | |
60 | ||
20095472 JG |
61 | * Begin with an uppercase letter. |
62 | * Be written in the present tense. | |
63 | * _Not_ exceed 72 characters in length. | |
64 | * _Not_ end with a period. | |
93794bcc | 65 | |
a7a35430 JG |
66 | In the case of bug fixes, the patch's subject must be prefixed with |
67 | `Fix:` and a suitable sub-system name. For instance, a patch | |
68 | addressing a bug in the session daemon should start with `Fix: | |
69 | sessiond:`. Patches targeting shared code can either use the namespace | |
70 | of the interface or of the internal library, whichever is more | |
71 | precise. | |
72 | ||
73 | A non-exhaustive list of common sub-system prefixes follows: | |
74 | ||
75 | * `relayd` (relay daemon). | |
76 | * `sessiond` (session daemon). | |
77 | * `lttng` (LTTng CLI client). | |
78 | * `ust-consumerd` (user space consumer daemon). | |
79 | * `kernel-consumerd` (kernel space consumer daemon). | |
80 | * `consumerd` (common consumer daemon). | |
81 | * `common` (internal `libcommon`). | |
82 | * `trace-chunk` (internal `lttng_trace_chunk_*` interface). | |
83 | * `lttng-ctl` (`liblttng-ctl` library). | |
84 | * `mi` (LTTng client's machine interface). | |
85 | ||
86 | When possible, the commit title should describe the issue _as | |
87 | observed_ and not the underlying cause. For instance, prefer `Fix: | |
88 | sessiond: hang on SIGTERM after session rotation` to `Fix: sessiond: | |
89 | unchecked status on exit`. | |
90 | ||
91 | The commit message's body must be as detailed as possible and explain | |
92 | the reasons behind the proposed change. Keep in mind that this message | |
93 | will be read in a number of years and must still be clear. Any related | |
93794bcc PP |
94 | [bug report(s)](https://bugs.lttng.org/projects/lttng-tools/issues) |
95 | should be mentioned at the end of the message using the `#123` format, | |
96 | where `123` is the bug number: | |
97 | ||
98 | * Use `Refs: #123` if the patch is related to bug 123, but does not | |
99 | fix it yet. | |
100 | * Use `Fixes: #123` to signify that this patch fixes the bug. | |
101 | ||
a7a35430 JG |
102 | In the case of bug fixes, the following structure must be used: |
103 | ||
104 | * Observed issue | |
105 | * Cause | |
106 | * Solution | |
107 | * **Optional**: Known drawbacks | |
108 | ||
109 | A short commit message can be used when submitting typo fixes or minor | |
110 | cleanups that don't introduce behaviour changes. | |
111 | ||
112 | When submitting a patch that affects existing code, implement changes | |
113 | to the existing code as prelude patches in a patch series. Explain why | |
114 | those changes are needed and how they make follow-up changes | |
115 | easier/possible. | |
116 | ||
93794bcc PP |
117 | Make sure to **sign-off** your submitted patches (the `-s` argument to |
118 | Git's `commit` and `format-patch` commands). | |
119 | ||
120 | Here's a complete example: | |
121 | ||
122 | ~~~ text | |
a7a35430 JG |
123 | Fix: relayd: missing thingy in the doodad folder on error |
124 | ||
125 | Observed issue | |
126 | ============== | |
127 | After a communication error, the relay daemon will not produce | |
128 | a thingy in the doodad folder. This results in the knickknack | |
129 | baring the foo. | |
130 | ||
131 | Steps to reproduce (list of commands or narrative description). | |
132 | ||
133 | Cause | |
134 | ===== | |
135 | The thingy_do_the_doodad() callback is only invoked when | |
136 | the thread responsible for receiving messages and dispatching | |
137 | them to the correct actors encounters an emoji. | |
138 | ||
139 | However, an emoji is not guaranteed to be present in the ELF | |
140 | section header [1]. | |
141 | ||
142 | Solution | |
143 | ======== | |
144 | Flushing the doodad on every reception of a thingo ensures that | |
145 | the thingy is present in the doodad folder even if a communication | |
146 | error occurs. | |
147 | ||
148 | Known drawbacks | |
149 | =============== | |
150 | Flushing the doodad too often may spam the widget and result in | |
151 | degradation of the gizmo. This doesn't matter right now since | |
152 | it happens exactly once per blue moon. | |
153 | ||
154 | If this becomes a serious issue, we could machine learn the MVP | |
155 | through the big O terminal. | |
156 | ||
157 | References | |
158 | ========== | |
159 | [1] https://www.thedocs.com/elf/proving-my-point-unambiguously.aspx | |
93794bcc PP |
160 | |
161 | Fixes: #321 | |
162 | Refs: #456 | |
163 | Refs: #1987 | |
164 | ||
165 | Signed-off-by: Jeanne Mance <jmeance@lttng.org> | |
166 | ~~~ | |
167 | ||
168 | Please note that patches should be **as focused as possible**. Do not, | |
169 | for instance, fix a bug and correct the indentation of an unrelated | |
170 | block of code as part of the same patch. | |
171 | ||
172 | The project contains a script, [`extras/checkpatch.pl`](extras/checkpatch.pl), | |
173 | that performs a number of checks on a patch to ensure it is ready for | |
174 | submission. Run this script on your patch and correct any reported | |
175 | errors before posting it to the mailing list: | |
176 | ||
177 | extras/checkpatch.pl --no-tree 0001-Fix...patch | |
178 | ||
179 | Once you are confident your patch meets the required guidelines, | |
180 | you may use Git's [`send-email`](https://git-scm.com/docs/git-send-email) | |
181 | command to send your patch to the mailing list: | |
182 | ||
183 | git send-email --suppress-cc=self --to lttng-dev@lists.lttng.org *.patch | |
184 | ||
185 | Make sure you are | |
186 | [subscribed](http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev) | |
187 | to the mailing list to follow and take part in discussions about your | |
188 | changes. You may join the file to an email as an attachment if you can't | |
189 | send the patch directly using <code>git send‑email</code>. | |
190 | ||
191 | ||
192 | ## Reviews | |
193 | ||
194 | Once your patch has been posted to the mailing list or as a GitHub | |
195 | pull request, other contributors may propose modifications. | |
196 | This is completely normal. This collaborative code review is an integral | |
197 | part of the open source development process in general and LTTng-tools | |
198 | makes no exception. | |
199 | ||
200 | Keep in mind that reviewing patches is a time-consuming process and, | |
201 | as such, may not be done right away. The delays may be affected by the | |
202 | current release cycle phase and the complexity of the proposed changes. | |
203 | If you think your patch might have been forgotten, please mention it on | |
204 | the [`#lttng`](irc://irc.oftc.net/lttng) IRC channel rather than | |
205 | resubmitting. | |
206 | ||
207 | ||
208 | ## Release cycle | |
209 | ||
210 | The LTTng-tools project follows a release cycle that alternates between | |
211 | development and release candidate (RC) phases. The master branch is | |
212 | feature-frozen during RC phases: only bug fixes are accepted during | |
213 | this period. However, patches adding new functionality may still be | |
214 | submitted and reviewed during the RC. The upcoming features and release | |
215 | dates are posted in a monthly digest on the mailing list. |