1 ==========================
2 Submitting Patches to Ceph
3 ==========================
5 This is based on Documentation/SubmittingPatches from the Linux kernel,
6 but has pared down significantly and updated based on the Ceph project's
9 The patch signing procedures and definitions are unmodified.
15 In order to keep the record of code attribution clean within the source
16 repository, follow these guidelines for signing patches submitted to the
17 project. These definitions are taken from those used by the Linux kernel
18 and many other open source projects.
24 To improve tracking of who did what, especially with patches that can
25 percolate to their final resting place in the kernel through several
26 layers of maintainers, we've introduced a "sign-off" procedure on
27 patches that are being emailed around.
29 The sign-off is a simple line at the end of the explanation for the
30 patch, which certifies that you wrote it or otherwise have the right to
31 pass it on as a open-source patch. The rules are pretty simple: if you
32 can certify the below:
34 Developer's Certificate of Origin 1.1
35 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
37 By making a contribution to this project, I certify that:
39 (a) The contribution was created in whole or in part by me and I
40 have the right to submit it under the open source license
41 indicated in the file; or
43 (b) The contribution is based upon previous work that, to the best
44 of my knowledge, is covered under an appropriate open source
45 license and I have the right under that license to submit that
46 work with modifications, whether created in whole or in part
47 by me, under the same open source license (unless I am
48 permitted to submit under a different license), as indicated
51 (c) The contribution was provided directly to me by some other
52 person who certified (a), (b) or (c) and I have not modified
55 (d) I understand and agree that this project and the contribution
56 are public and that a record of the contribution (including all
57 personal information I submit with it, including my sign-off) is
58 maintained indefinitely and may be redistributed consistent with
59 this project or the open source license(s) involved.
61 then you just add a line saying ::
63 Signed-off-by: Random J Developer <random@developer.example.org>
66 using your real name (sorry, no pseudonyms or anonymous contributions.)
68 Some people also put extra tags at the end. They'll just be ignored for
69 now, but you can do this to mark internal company procedures or just
70 point out some special detail about the sign-off.
72 If you are a subsystem or branch maintainer, sometimes you need to slightly
73 modify patches you receive in order to merge them, because the code is not
74 exactly the same in your tree and the submitters'. If you stick strictly to
75 rule (c), you should ask the submitter to rediff, but this is a totally
76 counter-productive waste of time and energy. Rule (b) allows you to adjust
77 the code, but then it is very impolite to change one submitter's code and
78 make them endorse your bugs. To solve this problem, it is recommended that
79 you add a line between the last Signed-off-by header and yours, indicating
80 the nature of your changes. While there is nothing mandatory about this, it
81 seems like prepending the description with your mail and/or name, all
82 enclosed in square brackets, is noticeable enough to make it obvious that
83 you are responsible for last-minute changes. Example ::
85 Signed-off-by: Random J Developer <random@developer.example.org>
86 [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
87 Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
89 This practise is particularly helpful if you maintain a stable branch and
90 want at the same time to credit the author, track changes, merge the fix,
91 and protect the submitter from complaints. Note that under no circumstances
92 can you change the author's identity (the From header), as it is the one
93 which appears in the changelog.
95 Special note to back-porters: It seems to be a common and useful practise
96 to insert an indication of the origin of a patch at the top of the commit
97 message (just after the subject line) to facilitate tracking. For instance,
98 here's what we see in 2.6-stable ::
100 Date: Tue May 13 19:10:30 2008 +0000
102 SCSI: libiscsi regression in 2.6.25: fix nop timer handling
104 commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream
106 And here's what appears in 2.4 ::
108 Date: Tue May 13 22:12:27 2008 +0200
110 wireless, airo: waitbusy() won't delay
112 [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
114 Whatever the format, this information provides a valuable help to people
115 tracking your trees, and to people trying to trouble-shoot bugs in your
119 2. When to use ``Acked-by:`` and ``Cc:``
120 ----------------------------------------
122 The ``Signed-off-by:`` tag indicates that the signer was involved in the
123 development of the patch, or that he/she was in the patch's delivery path.
125 If a person was not directly involved in the preparation or handling of a
126 patch but wishes to signify and record their approval of it then they can
127 arrange to have an ``Acked-by:`` line added to the patch's changelog.
129 ``Acked-by:`` is often used by the maintainer of the affected code when that
130 maintainer neither contributed to nor forwarded the patch.
132 ``Acked-by:`` is not as formal as ``Signed-off-by:``. It is a record that the acker
133 has at least reviewed the patch and has indicated acceptance. Hence patch
134 mergers will sometimes manually convert an acker's "yep, looks good to me"
135 into an ``Acked-by:``.
137 ``Acked-by:`` does not necessarily indicate acknowledgement of the entire patch.
138 For example, if a patch affects multiple subsystems and has an ``Acked-by:`` from
139 one subsystem maintainer then this usually indicates acknowledgement of just
140 the part which affects that maintainer's code. Judgement should be used here.
141 When in doubt people should refer to the original discussion in the mailing
144 If a person has had the opportunity to comment on a patch, but has not
145 provided such comments, you may optionally add a "Cc:" tag to the patch.
146 This is the only tag which might be added without an explicit action by the
147 person it names. This tag documents that potentially interested parties
148 have been included in the discussion
151 3. Using ``Reported-by:``, ``Tested-by:`` and ``Reviewed-by:``
152 --------------------------------------------------------------
154 If this patch fixes a problem reported by somebody else, consider adding a
155 Reported-by: tag to credit the reporter for their contribution. This tag should
156 not be added without the reporter's permission, especially if the problem was
157 not reported in a public forum. That said, if we diligently credit our bug
158 reporters, they will, hopefully, be inspired to help us again in the future.
160 A ``Tested-by:`` tag indicates that the patch has been successfully tested (in
161 some environment) by the person named. This tag informs maintainers that
162 some testing has been performed, provides a means to locate testers for
163 future patches, and ensures credit for the testers.
165 ``Reviewed-by:``, instead, indicates that the patch has been reviewed and found
166 acceptable according to the Reviewer's Statement:
168 Reviewer's statement of oversight
169 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
171 By offering my ``Reviewed-by:`` tag, I state that:
173 (a) I have carried out a technical review of this patch to
174 evaluate its appropriateness and readiness for inclusion into
177 (b) Any problems, concerns, or questions relating to the patch
178 have been communicated back to the submitter. I am satisfied
179 with the submitter's response to my comments.
181 (c) While there may be things that could be improved with this
182 submission, I believe that it is, at this time, (1) a
183 worthwhile modification to the kernel, and (2) free of known
184 issues which would argue against its inclusion.
186 (d) While I have reviewed the patch and believe it to be sound, I
187 do not (unless explicitly stated elsewhere) make any
188 warranties or guarantees that it will achieve its stated
189 purpose or function properly in any given situation.
191 A ``Reviewed-by`` tag is a statement of opinion that the patch is an
192 appropriate modification of the kernel without any remaining serious
193 technical issues. Any interested reviewer (who has done the work) can
194 offer a ``Reviewed-by`` tag for a patch. This tag serves to give credit to
195 reviewers and to inform maintainers of the degree of review which has been
196 done on the patch. ``Reviewed-by:`` tags, when supplied by reviewers known to
197 understand the subject area and to perform thorough reviews, will normally
198 increase the likelihood of your patch getting into the kernel.
201 PREPARING AND SENDING PATCHES
202 =============================
204 The upstream repository is managed by Git. You will find that it
205 is easiest to work on the project and submit changes by using the
206 git tools, both for managing your own code and for preparing and
209 The project will generally accept code either by pulling code directly from
210 a published git tree (usually on github), or via patches emailed directly
211 to the email list (ceph-devel@vger.kernel.org). For the kernel client,
212 patches are expected to be reviewed in the email list. And for everything
213 else, github is preferred due to the convenience of the 'pull request'
217 1. Github pull request
218 ----------------------
220 The preferred way to submit code is by publishing your patches in a branch
221 in your github fork of the ceph repository and then submitting a github
224 For example, prepare your changes
228 # ...code furiously...
229 $ git commit # git gui is also quite convenient
230 $ git push origin mything
232 Then submit a pull request at
234 https://github.com/ceph/ceph/pulls
236 and click 'New pull request'. See :ref:`_title_of_commit` for our naming
237 convention of pull requests. The 'hub' command-line tool, available from
239 https://github.com/github/hub
241 allows you to submit pull requests directly from the command line
245 $ hub pull-request -b ceph:master -h you:mything
247 Pull requests appear in the review queue at
249 https://github.com/organizations/ceph/dashboard/pulls
251 You may want to ping a developer in #ceph-devel on irc.oftc.net or on the
252 email list to ensure your submission is noticed.
254 When addressing review comments, can should either add additional patches to
255 your branch or (better yet) squash those changes into the relevant commits so
256 that the sequence of changes is "clean" and gets things right the first time.
257 The 'git rebase -i' command is very helpful in this process. Once you have
258 updated your local branch, you can simply force-push to the existing branch
259 in your public repository that is referenced by the pull request with
263 $ git push -f origin mything
265 and your changes will be visible from the existing pull-request. You may want
266 to ping the reviewer again or comment on the pull request to ensure the updates
269 Sometimes your change could be based on an outdated parent commit and has
270 conflicts with the latest target branch, then you need to fetch the updates
271 from the remote branch, rebase your change onto it, and resolve the conflicts
272 before doing the force-push
276 $ git pull --rebase origin target-branch
278 So that the pull request does not contain any "merge" commit. Instead of "merging"
279 the target branch, we expect a linear history in a pull request where you
280 commit on top of the remote branch.
282 Q: Which branch should I target in my pull request?
284 A: The target branch depends on the nature of your change:
286 If you are adding a feature, target the "master" branch in your pull
289 If you are fixing a bug, target the named branch corresponding to the
290 major version that is currently in development. For example, if
291 Infernalis is the latest stable release and Jewel is development, target
292 the "jewel" branch for bugfixes. The Ceph core developers will
293 periodically merge this named branch into "master". When this happens,
294 the master branch will contain your fix as well.
296 If you are fixing a bug (see above) *and* the bug exists in older stable
297 branches (for example, the "hammer" or "infernalis" branches), then you
298 should file a Redmine ticket describing your issue and fill out the
299 "Backport: <branchname>" form field. This will notify other developers that
300 your commit should be cherry-picked to one or more stable branches. Then,
301 target the "master" branch in your pull request.
303 For example, you should set "Backport: jewel, kraken" in your Redmine ticket
304 to indicate that you are fixing a bug that exists on the "jewel" and
305 "kraken" branches and that you desire that your change be cherry-picked to
306 those branches after it is merged into master.
308 Q: How to include ``Reviewed-by: tag(s)`` in my pull request?
310 A: You don't. If someone reviews your pull request, they should indicate they
311 have done so by commenting on it with "+1", "looks good to me", "LGTM",
312 and/or the entire "Reviewed-by: ..." line with their name and email address.
314 The developer merging the pull request should note positive reviews and
315 include the appropriate Reviewed-by: lines in the merge commit.
318 2. Patch submission via ceph-devel@vger.kernel.org
319 --------------------------------------------------
321 The best way to generate a patch for manual submission is to work from
322 a Git checkout of the Ceph source code. You can then generate patches
323 with the 'git format-patch' command. For example,
327 $ git format-patch HEAD^^ -o mything
329 will take the last two commits and generate patches in the mything/
330 directory. The commit you specify on the command line is the
331 'upstream' commit that you are diffing against. Note that it does
332 not necessarily have to be an ancestor of your current commit. You
333 can do something like
337 $ git checkout -b mything
338 # ... do lots of stuff ...
340 # ...find out that origin/unstable has also moved forward...
341 $ git format-patch origin/unstable -o mything
343 and the patches will be against origin/unstable.
345 The ``-o`` dir is optional; if left off, the patch(es) will appear in
346 the current directory. This can quickly get messy.
348 You can also add ``--cover-letter`` and get a '0000' patch in the
349 mything/ directory. That can be updated to include any overview
350 stuff for a multipart patch series. If it's a single patch, don't
353 Make sure your patch does not include any extra files which do not
354 belong in a patch submission. Make sure to review your patch -after-
355 generated it with ``diff(1)``, to ensure accuracy.
357 If your changes produce a lot of deltas, you may want to look into
358 splitting them into individual patches which modify things in
359 logical stages. This will facilitate easier reviewing by other
360 kernel developers, very important if you want your patch accepted.
361 There are a number of scripts which can aid in this.
363 The ``git send-email`` command make it super easy to send patches
364 (particularly those prepared with git format patch). It is careful to
365 format the emails correctly so that you don't have to worry about your
366 email client mangling whitespace or otherwise screwing things up. It
371 $ git send-email --to ceph-devel@vger.kernel.org my.patch
373 for a single patch, or
377 $ git send-email --to ceph-devel@vger.kernel.org mything
379 to send a whole patch series (prepared with, say, git format-patch).
382 3. Describe your changes
383 ------------------------
385 Describe the technical detail of the change(s) your patch includes.
389 Title of pull requests and title of commits
390 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
392 The text up to the first empty line in a commit message is the commit
393 title. Ideally it is a single short line of at most 72 characters,
394 summarizing the change. It is required to prefix it with the
395 subsystem or module you are changing. For instance, the prefix
396 could be "doc:", "osd:", or "common:". One can use::
400 for more examples. Please use this "subsystem: short description"
401 convention for naming pull requests (PRs) also, as it feeds directly
402 into the script that generates release notes and it's tedious to clean
403 up at release time. This document places no limit on the length of PR
404 titles, but be aware that they are subject to editing as part of the
410 Be as specific as possible. The WORST descriptions possible include
411 things like "update driver X", "bug fix for driver X", or "this patch
412 includes updates for subsystem X. Please apply."
414 If your description starts to get long, that's a sign that you probably
415 need to split up your patch. See :ref:`split_changes`.
417 When you submit or resubmit a patch or patch series, include the
418 complete patch description and justification for it. Don't just
419 say that this is version N of the patch (series). Don't expect the
420 patch merger to refer back to earlier patch versions or referenced
421 URLs to find the patch description and put that into the patch.
422 I.e., the patch (series) and its description should be self-contained.
423 This benefits both the patch merger(s) and reviewers. Some reviewers
424 probably didn't even receive earlier versions of the patch.
429 If the patch fixes a logged bug entry, refer to that bug entry by
430 URL. In particular, if this patch fixes one or more issues
431 tracked by http://tracker.ceph.com, consider adding a ``Fixes:`` tag to
432 connect this change to addressed issue(s). So a line saying ::
434 Fixes: http://tracker.ceph.com/issues/12345
436 is added before the ``Signed-off-by:`` line stating that this commit
437 addresses http://tracker.ceph.com/issues/12345. It helps the reviewer to
438 get more context of this bug, so she/he can hence update the issue on
439 the bug tracker accordingly.
441 So a typical commit message for revising the document could look like::
443 doc: add "--foo" option to bar
445 * update the man page for bar with the newly added "--foo" option.
448 Fixes: http://tracker.ceph.com/issues/12345
449 Signed-off-by: Random J Developer <random@developer.example.org>
453 4. Separate your changes
454 ------------------------
456 Separate *logical changes* into a single patch file.
458 For example, if your changes include both bug fixes and performance
459 enhancements for a single driver, separate those changes into two
460 or more patches. If your changes include an API update, and a new
461 driver which uses that new API, separate those into two patches.
463 On the other hand, if you make a single change to numerous files,
464 group those changes into a single patch. Thus a single logical change
465 is contained within a single patch.
467 If one patch depends on another patch in order for a change to be
468 complete, that is OK. Simply note "this patch depends on patch X"
469 in your patch description.
471 If you cannot condense your patch set into a smaller set of patches,
472 then only post say 15 or so at a time and wait for review and integration.
474 5. Document your changes
475 ------------------------
477 If you have added or modified any user-facing functionality, such
478 as CLI commands or their output, then the patch series or pull request
479 must include appropriate updates to documentation.
481 It is the submitter's responsibility to make the changes, and the reviewer's
482 responsibility to make sure they are not merging changes that do not
483 have the needed updates to documentation.
485 Where there are areas that have absent documentation, or there is no
486 clear place to note the change that is being made, the reviewer should
487 contact the component lead, who should arrange for the missing section
488 to be created with sufficient detail for the patch submitter to
489 document their changes.
491 When writing and/or editing documentation, follow the Google Developer
492 Documentation Style Guide: https://developers.google.com/style/
494 6. Style check your changes
495 ---------------------------
497 Check your patch for basic style violations, details of which can be
498 found in CodingStyle.
501 7. No MIME, no links, no compression, no attachments. Just plain text
502 ----------------------------------------------------------------------
504 Developers need to be able to read and comment on the changes you are
505 submitting. It is important for a kernel developer to be able to
506 "quote" your changes, using standard e-mail tools, so that they may
507 comment on specific portions of your code.
509 For this reason, all patches should be submitting e-mail "inline".
510 WARNING: Be wary of your editor's word-wrap corrupting your patch,
511 if you choose to cut-n-paste your patch.
513 Do not attach the patch as a MIME attachment, compressed or not.
514 Many popular e-mail applications will not always transmit a MIME
515 attachment as plain text, making it impossible to comment on your
516 code. A MIME attachment also takes Linus a bit more time to process,
517 decreasing the likelihood of your MIME-attached change being accepted.
519 Exception: If your mailer is mangling patches then someone may ask
520 you to re-send them using MIME.