-.. _developer_policy:
-
=====================
LLVM Developer Policy
=====================
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
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:
projects / oota-llvm.git / blobdiff