From: Chandler Carruth Date: Fri, 10 Jan 2014 00:08:34 +0000 (+0000) Subject: Update the developer policy to more clearly spell out the steps for X-Git-Url: http://plrg.eecs.uci.edu/git/?p=oota-llvm.git;a=commitdiff_plain;h=36c48cad0d14cb1679f494c811554198308c4bc1 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 --- diff --git a/docs/DeveloperPolicy.rst b/docs/DeveloperPolicy.rst index ea5a7d1b66b..4ebf0f7dd91 100644 --- a/docs/DeveloperPolicy.rst +++ b/docs/DeveloperPolicy.rst @@ -74,8 +74,8 @@ that notices of confidentiality or non-disclosure cannot be respected. .. _patch: .. _one-off patches: -Making a Patch --------------- +Making and Submitting a Patch +----------------------------- When making a patch for review, the goal is to make it as easy for the reviewer to read it as possible. As such, we recommend that you: @@ -97,6 +97,12 @@ to read it as possible. As such, we recommend that you: script, please separate out those changes into a separate patch from the rest of your changes. +Once your patch is ready, submit it by emailing it to the appropriate project's +commit mailing list (or commit it directly if applicable). Alternatively, some +patches get sent to the project's development list or component of the LLVM bug +tracker, but the commit list is the primary place for reviews and should +generally be preferred. + When sending a patch to a mailing list, it is a good idea to send it as an *attachment* to the message, not embedded into the text of the message. This ensures that your mailer will not mangle the patch when it sends it (e.g. by @@ -125,7 +131,8 @@ software. We generally follow these policies: #. All developers are required to have significant changes reviewed before they are committed to the repository. -#. Code reviews are conducted by email, usually on the llvm-commits list. +#. Code reviews are conducted by email on the relevant project's commit mailing + list, or alternatively on the project's development list or bug tracker. #. Code can be reviewed either before it is committed or after. We expect major changes to be reviewed before being committed, but smaller changes (or @@ -413,15 +420,24 @@ to go about making the change. Attribution of Changes ---------------------- -We believe in correct attribution of contributions to their contributors. -However, we do not want the source code to be littered with random attributions -"this code written by J. Random Hacker" (this is noisy and distracting). In -practice, the revision control system keeps a perfect history of who changed -what, and the CREDITS.txt file describes higher-level contributions. If you -commit a patch for someone else, please say "patch contributed by J. Random -Hacker!" in the commit message. +When contributors submit a patch to an LLVM project, other developers with +commit access may commit it for the author once appropriate (based on the +progression of code review, etc.). When doing so, it is important to retain +correct attribution of contributions to their contributors. However, we do not +want the source code to be littered with random attributions "this code written +by J. Random Hacker" (this is noisy and distracting). In practice, the revision +control system keeps a perfect history of who changed what, and the CREDITS.txt +file describes higher-level contributions. If you commit a patch for someone +else, please say "patch contributed by J. Random Hacker!" in the commit +message. Overall, please do not add contributor names to the source code. + +Also, don't commit patches authored by others unless they have submitted the +patch to the project or you have been authorized to submit them on their behalf +(you work together and your company authorized you to contribute the patches, +etc.). The author should first submit them to the relevant project's commit +list, development list, or LLVM bug tracker component. If someone sends you +a patch privately, encourage them to submit it to the appropriate list first. -Overall, please do not add contributor names to the source code. .. _copyright-license-patents: