[PATCH] Clarify that patch submission process

[Alp Toker]

Hi Chandler,

This is a sensible and welcome change.

Looks good overall, only small style nitpicks inline...


On 09/01/2014 22:30, Chandler Carruth wrote:
> This patch just tries to write down common existing practice and clarify that when folks are committing patches authored by others, the authors should really submit them to whichever project first.
>
> http://llvm-reviews.chandlerc.com/D2528
>
> Files:
>    docs/DeveloperPolicy.rst
>
> Index: docs/DeveloperPolicy.rst
> ===================================================================
> --- docs/DeveloperPolicy.rst
> +++ docs/DeveloperPolicy.rst
> @@ -74,8 +74,8 @@
>   .. _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 @@
>      script, please separate out those changes into a separate patch from the rest
>      of your changes.
>   
> +Once you have your patch ready, you submit it by emailing it to the appropriate

Style nit. The rest of the document is in the imperative.

"Once your patch is ready, submit it..."

> +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 @@
>   #. 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, but alternatively on the project's development list or bug tracker.

"or alternatively"

>   
>   #. 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 @@
>   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 people submit a patch to an LLVM project, other developers with commit

s/people/contributors/

> +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:
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-- 
http://www.nuanti.com
the browser experts