Lines Matching +full:commits +full:-
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
55 subscribe to the "commits" mailing list for the subproject you're interested in,
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
60 "commits" list and paying attention to changes being made by others is a good
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 -----------------------------
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``
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 ------------
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
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``
269 bots will directly email you if a group of commits that included yours caused a
273 Commits that violate these quality standards (e.g. are very broken) may be
275 progress. The developer is welcome to re-commit the change after the problem has
281 ---------------
300 * The title should be concise. Because all commits are emailed to the list with
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
325 and in-code comments, ex. capitalization, full stop, etc.
334 omissions can be handled by sending a reply to the commits mailing list.
337 -----------------------
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.
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,
374 obvious. This is clearly a subjective decision --- we simply expect you to
381 responsibility for), with the proviso that such commits must not break the
382 build. This is a "trust but verify" policy, and commits of this nature are
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 ----------------------
487 file describes higher-level contributions. If you commit a patch for someone
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