llvm.org GIT mirror llvm / 36c48ca
Update the developer policy to more clearly spell out the steps for contributors to submit patches to the LLVM project. Thanks to Danny, Chris, Alp, and others for reviewing. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198901 91177308-0d34-0410-b5e6-96231b3b80d8 Chandler Carruth 6 years ago
1 changed file(s) with 28 addition(s) and 12 deletion(s). Raw diff Collapse all Expand all
7373 .. _patch:
7474 .. _one-off patches:
7575
76 Making a Patch
77 --------------
76 Making and Submitting a Patch
77 -----------------------------
7878
7979 When making a patch for review, the goal is to make it as easy for the reviewer
8080 to read it as possible. As such, we recommend that you:
9595 #. If you are modifying generated files, such as the top-level ``configure``
9696 script, please separate out those changes into a separate patch from the rest
9797 of your changes.
98
99 Once your patch is ready, submit it by emailing it to the appropriate project's
100 commit mailing list (or commit it directly if applicable). Alternatively, some
101 patches get sent to the project's development list or component of the LLVM bug
102 tracker, but the commit list is the primary place for reviews and should
103 generally be preferred.
98104
99105 When sending a patch to a mailing list, it is a good idea to send it as an
100106 *attachment* to the message, not embedded into the text of the message. This
124130 #. All developers are required to have significant changes reviewed before they
125131 are committed to the repository.
126132
127 #. Code reviews are conducted by email, usually on the llvm-commits list.
133 #. Code reviews are conducted by email on the relevant project's commit mailing
134 list, or alternatively on the project's development list or bug tracker.
128135
129136 #. Code can be reviewed either before it is committed or after. We expect major
130137 changes to be reviewed before being committed, but smaller changes (or
412419 Attribution of Changes
413420 ----------------------
414421
415 We believe in correct attribution of contributions to their contributors.
416 However, we do not want the source code to be littered with random attributions
417 "this code written by J. Random Hacker" (this is noisy and distracting). In
418 practice, the revision control system keeps a perfect history of who changed
419 what, and the CREDITS.txt file describes higher-level contributions. If you
420 commit a patch for someone else, please say "patch contributed by J. Random
421 Hacker!" in the commit message.
422
423 Overall, please do not add contributor names to the source code.
422 When contributors submit a patch to an LLVM project, other developers with
423 commit access may commit it for the author once appropriate (based on the
424 progression of code review, etc.). When doing so, it is important to retain
425 correct attribution of contributions to their contributors. However, we do not
426 want the source code to be littered with random attributions "this code written
427 by J. Random Hacker" (this is noisy and distracting). In practice, the revision
428 control system keeps a perfect history of who changed what, and the CREDITS.txt
429 file describes higher-level contributions. If you commit a patch for someone
430 else, please say "patch contributed by J. Random Hacker!" in the commit
431 message. Overall, please do not add contributor names to the source code.
432
433 Also, don't commit patches authored by others unless they have submitted the
434 patch to the project or you have been authorized to submit them on their behalf
435 (you work together and your company authorized you to contribute the patches,
436 etc.). The author should first submit them to the relevant project's commit
437 list, development list, or LLVM bug tracker component. If someone sends you
438 a patch privately, encourage them to submit it to the appropriate list first.
439
424440
425441 .. _copyright-license-patents:
426442