[PATCH] D128645: Update developer policy.

[Edd Barrett via Phabricator via llvm-commits]

vext01 created this revision.
vext01 added a reviewer: t.p.northover.
Herald added a project: All.
vext01 requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

I've recently gone though the process of getting commit rights and have raised a few diffs already.

The developer policy is a little out of date in some places. This change updates them based upon my own personal experience.

Namely:

- diffs are not passed around on mailing lists any more.
- diffs should be `-U 999999`
- you don't have to respond to any automated email.

Looks good?


https://reviews.llvm.org/D128645

Files:
  llvm/docs/DeveloperPolicy.rst


Index: llvm/docs/DeveloperPolicy.rst
===================================================================
--- llvm/docs/DeveloperPolicy.rst
+++ llvm/docs/DeveloperPolicy.rst
@@ -84,34 +84,12 @@
    patches may not apply correctly if the underlying code changes between the
    time the patch was created and the time it is applied.
 
-#. Patches should be made with ``git format-patch``, or similar (see special
-   commands for `Requesting Phabricator review via the web interface
-   <Phabricator.html#phabricator-request-review-web>`_ ). If you use a
-   different tool, make sure it uses the ``diff -u`` format and that it
-   doesn't contain clutter which makes it hard to read.
-
-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
-making whitespace changes or by wrapping lines).
-
-*For Thunderbird users:* Before submitting a patch, please open *Preferences >
-Advanced > General > Config Editor*, find the key
-``mail.content_disposition_type``, and set its value to ``1``. Without this
-setting, Thunderbird sends your attachment using ``Content-Disposition: inline``
-rather than ``Content-Disposition: attachment``. Apple Mail gamely displays such
-a file inline, making it difficult to work with for reviewers using that
-program.
-
-When submitting patches, please do not add confidentiality or non-disclosure
-notices to the patches themselves.  These notices conflict with the LLVM
-licensing terms and may result in your contribution being excluded.
+#. Patches should be unified diffs with "infinte context" (i.e. using something
+   like `git diff -U 999999 main`).
+
+#. Once you have created your patch, create a
+   `Phabricator review <Phabricator.html#phabricator-request-review-web>`_ for
+   it (or commit it directly if applicable).
 
 .. _code review:
 
@@ -416,10 +394,6 @@
 provide the name and email address you would like to use in the Author
 property of the commit.
 
-Your first commit to a repository may require the autogenerated email to be
-approved by a moderator of the mailing list.
-This is normal and will be done when the mailing list owner has time.
-
 If you have recently been granted commit access, these policies apply:
 
 #. You are granted *commit-after-approval* to all parts of LLVM. For


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D128645.440210.patch
Type: text/x-patch
Size: 2767 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220627/63966dab/attachment.bin>