Lines Matching +full:commit +full:- +full:message +full:- +full:check
28 policies <copyright-license-patents>` with contributors to the project.
31 contributing one-off patches can do so in an informal way by sending them to the
32 `llvm-commits mailing list
33 <http://lists.llvm.org/mailman/listinfo/llvm-commits>`_ and engaging another
40 always welcome `one-off patches`_ from people who do not routinely contribute to
47 -------------
50 the projects you are interested in, such as `llvm-dev
51 <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ for LLVM, `cfe-dev
52 <http://lists.llvm.org/mailman/listinfo/cfe-dev>`_ for Clang, or `lldb-dev
53 <http://lists.llvm.org/mailman/listinfo/lldb-dev>`_ for LLDB. If you are
56 such as `llvm-commits
57 <http://lists.llvm.org/mailman/listinfo/llvm-commits>`_, `cfe-commits
58 <http://lists.llvm.org/mailman/listinfo/cfe-commits>`_, or `lldb-commits
59 <http://lists.llvm.org/mailman/listinfo/lldb-commits>`_. Reading the
65 Bugzilla <http://llvm.org/bugs/>`_ and preferably subscribe to the `llvm-bugs
66 <http://lists.llvm.org/mailman/listinfo/llvm-bugs>`_ email list to keep track
72 that notices of confidentiality or non-disclosure cannot be respected.
75 .. _one-off patches:
78 -----------------------------
85 how to check out SVN trunk, please see the `Getting Started
93 different tool, make sure it uses the ``diff -u`` format and that it
96 #. If you are modifying generated files, such as the top-level ``configure``
101 commit mailing list (or commit it directly if applicable). Alternatively, some
103 tracker, but the commit list is the primary place for reviews and should
107 *attachment* to the message, not embedded into the text of the message. This
114 setting, Thunderbird sends your attachment using ``Content-Disposition: inline``
115 rather than ``Content-Disposition: attachment``. Apple Mail gamely displays such
119 When submitting patches, please do not add confidentiality or non-disclosure
126 ------------
134 #. Code reviews are conducted by email on the relevant project's commit mailing
139 changes where the developer owns the component) can be reviewed after commit.
142 all necessary review-related changes.
173 -----------
177 of code review plus post-commit review for trusted maintainers. Having both is
179 the right thing most of the time, and only commit patches without pre-commit
186 responsibility of a code owner is to ensure that a commit to their area of the
199 interests change, and unexpected things happen, code ownership is purely opt-in,
206 ----------
212 directory. The appropriate sub-directory should be selected (see the
219 entire failing program into ``llvm/test`` as this creates a *time-to-test*
224 etc) should be added to the ``llvm-test`` test suite. The llvm-test suite is
229 -------
243 #. The code must not cause regressions on a reasonable subset of llvm-test,
246 might be something like "``llvm-test/MultiSource/Benchmarks``".
253 * The changes should not cause any correctness regressions in the ``llvm-test``
268 to check the nightly testers for regressions the day after your change. Build
270 failure. You are expected to check the build bot messages to see if they are
275 progress. The developer is welcome to re-commit the change after the problem has
280 Commit messages
281 ---------------
283 Although we don't enforce the format of commit messages, we prefer that
288 Most importantly, the contents of the message should be carefully written to
295 Below are some guidelines about the format of the message itself:
297 * Separate the commit message into title, body and, if you're not the original
305 back-end or optimization pass), it is customary to add a tag to the
307 or "[OpenMP] ...". This helps email filters and searches for post-commit
317 * If the patch fixes a bug in bugzilla, please include the PR# in the message.
325 and in-code comments, ex. capitalization, full stop, etc.
327 * If the commit is a bug fix on top of another recently committed patch, or a
329 related commit. This could be as simple as "Revert rNNNN because it caused
336 Obtaining Commit Access
337 -----------------------
339 We grant commit access to contributors with a track record of submitting high
340 quality patches. If you would like commit access, please send an email to
343 #. The user name you want to commit with, e.g. "hacker".
345 #. The full name and email address you want message to llvm-commits to come
351 comes with apache) in *crypt* mode (often enabled with "``-d``"), or find a web
353 hashes. These are significantly longer than a crypt hash - e.g.
356 Once you've been granted commit access, you should be able to check out an LLVM
358 anonymous URL of "http://llvm.org/...". The first time you commit you'll have
360 untrusted key; you can ignore this. To verify that your commit access works,
361 please do a test commit (e.g. change a comment or add a blank line). Your first
362 commit to a repository may require the autogenerated email to be approved by a
366 If you have recently been granted commit access, these policies apply:
368 #. You are granted *commit-after-approval* to all parts of LLVM. To get
369 approval, submit a `patch`_ to `llvm-commits
370 <http://lists.llvm.org/mailman/listinfo/llvm-commits>`_. When approved,
371 you may commit it yourself.
373 #. You are allowed to commit patches without approval which you think are
374 obvious. This is clearly a subjective decision --- we simply expect you to
379 #. You are allowed to commit patches without approval to those portions of LLVM
386 cause commit access to be revoked.
396 ---------------------
399 to LLVM, they should inform the community with an email to the `llvm-dev
400 <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ email list, to the extent
418 as a series of `incremental changes`_, not as a long-term development branch.
423 -----------------------
426 patches. We have a strong dislike for huge changes or long-term development
427 branches. Long-term development branches have a number of drawbacks:
454 * The remaining inter-related work should be decomposed into unrelated sets of
478 ----------------------
481 commit access may commit it for the author once appropriate (based on the
487 file describes higher-level contributions. If you commit a patch for someone
489 by the `commit messages`_ section. Overall, please do not add contributor names
492 Also, don't commit patches authored by others unless they have submitted the
495 etc.). The author should first submit them to the relevant project's commit
501 --------------------------
517 ``compatibility-X.Y.ll``. The corresponding bitcode file should be assembled
518 using the X.Y build and committed as ``compatibility-X.Y.ll.bc``.
526 * Non-debug metadata is defined to be safe to drop, so a valid way to upgrade
531 ----------------
557 .. _copyright-license-patents:
565 are not lawyers --- please seek legal counsel from an attorney.
571 <http://www.opensource.org/licenses/UoI-NCSA.php>`_ (with portions dual licensed
572 under the `MIT License <http://www.opensource.org/licenses/mit-license.php>`_,
577 ---------
591 contradicts the license (which is a liberal BSD-style license), and that the
598 -------
604 <http://www.opensource.org/licenses/UoI-NCSA.php>`_, which boils down to
618 `License <http://www.opensource.org/licenses/UoI-NCSA.php>`_ if further
623 <http://www.opensource.org/licenses/mit-license.php>`_, which does not contain
642 and GPL-containing subprojects are kept in separate SVN repositories whose
647 List <mailto:llvm-dev@lists.llvm.org>`_.
650 -------
659 patent-related trouble with their changes (including from third parties). If