[PATCH] Clarify that patch submission process

[Daniel Berlin]

This looks fine to me. I'm always in favor of as simple of verbiage as
works, but since this has actually come up and caused issues, it seems
completely worth addressing to me.

On Thu, Jan 9, 2014 at 2:39 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> Adding Chris and Danny to review this... It's a pretty simple patch over
> all.
>
>
> On Thu, Jan 9, 2014 at 2:30 PM, Chandler Carruth <chandlerc at gmail.com>
> 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
>> +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.
>>
>>  #. 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
>> +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
>>
>