-.. _developer_policy:
-
=====================
LLVM Developer Policy
=====================
#. Keep the top of Subversion trees as stable as possible.
-#. Establish awareness of the project's `copyright, license, and patent
- policies`_ with contributors to the project.
+#. Establish awareness of the project's :ref:`copyright, license, and patent
+ policies <copyright-license-patents>` with contributors to the project.
This policy is aimed at frequent contributors to LLVM. People interested in
contributing one-off patches can do so in an informal way by sending them to the
all necessary review-related changes.
#. Code review can be an iterative process, which continues until the patch is
- ready to be committed.
+ ready to be committed. Specifically, once a patch is sent out for review, it
+ needs an explicit "looks good" before it is submitted. Do not assume silent
+ approval, or request active objections to the patch with a deadline.
+
+Sometimes code reviews will take longer than you would hope for, especially for
+larger features. Accepted ways to speed up review times for your patches are:
+
+* Review other people's patches. If you help out, everybody will be more
+ willing to do the same for you; goodwill is our currency.
+* Ping the patch. If it is urgent, provide reasons why it is important to you to
+ get this patch landed and ping it every couple of days. If it is
+ not urgent, the common courtesy ping rate is one week. Remember that you're
+ asking for valuable time from other professional developers.
+* Ask for help on IRC. Developers on IRC will be able to either help you
+ directly, or tell you who might be a good reviewer.
+* Split your patch into multiple smaller patches that build on each other. The
+ smaller your patch, the higher the probability that somebody will take a quick
+ look at it.
Developers should participate in code reviews as both reviewers and
reviewees. If someone is kind enough to review your code, you should return the
on a patch, but only people with Subversion write access can approve it.
There is a web based code review tool that can optionally be used
-for code reviews. See the documentation on `Code Reviews with
-Phabricator <Phabricator.html>`_.
+for code reviews. See :doc:`Phabricator`.
Code Owners
-----------
features added. Some tips for getting your testcase approved:
* All feature and regression test cases are added to the ``llvm/test``
- directory. The appropriate sub-directory should be selected (see the `Testing
- Guide <TestingGuide.html>`_ for details).
+ directory. The appropriate sub-directory should be selected (see the
+ :doc:`Testing Guide <TestingGuide>` for details).
* Test cases should be written in `LLVM assembly language <LangRef.html>`_
unless the feature or regression being tested requires another language
from, e.g. "J. Random Hacker <hacker@yoyodyne.com>".
#. A "password hash" of the password you want to use, e.g. "``2ACR96qjUqsyM``".
- Note that you don't ever tell us what your password is, you just give it to
+ Note that you don't ever tell us what your password is; you just give it to
us in an encrypted form. To get this, run "``htpasswd``" (a utility that
comes with apache) in crypt mode (often enabled with "``-d``"), or find a web
page that will do it for you.
tree with an SVN URL of "https://username@llvm.org/..." instead of the normal
anonymous URL of "http://llvm.org/...". The first time you commit you'll have
to type in your password. Note that you may get a warning from SVN about an
-untrusted key, you can ignore this. To verify that your commit access works,
+untrusted key; you can ignore this. To verify that your commit access works,
please do a test commit (e.g. change a comment or add a blank line). Your first
commit to a repository may require the autogenerated email to be approved by a
-mailing list. This is normal, and will be done when the mailing list owner has
+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. To get
approval, submit a `patch`_ to `llvm-commits
- <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_. When approved
+ <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_. When approved,
you may commit it yourself.
#. You are allowed to commit patches without approval which you think are
#. You are allowed to commit patches without approval to those portions of LLVM
that you have contributed or maintain (i.e., have been assigned
responsibility for), with the proviso that such commits must not break the
- build. This is a "trust but verify" policy and commits of this nature are
+ build. This is a "trust but verify" policy, and commits of this nature are
reviewed after they are committed.
#. Multiple violations of these policies or a single egregious violation may
In any case, your changes are still subject to `code review`_ (either before or
after they are committed, depending on the nature of the change). You are
encouraged to review other peoples' patches as well, but you aren't required
-to.
+to do so.
.. _discuss the change/gather consensus:
Overall, please do not add contributor names to the source code.
-.. _copyright, license, and patent policies:
+.. _copyright-license-patents:
Copyright, License, and Patents
===============================
projects / oota-llvm.git / blobdiff