diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index 8561a7a4af3..16238f2c084 100644 --- a/docs/DeveloperPolicy.html +++ b/docs/DeveloperPolicy.html @@ -54,47 +54,13 @@ the policy in clear terms, we hope each developer can know ahead of time what to expect when making LLVM contributions.

- -
Terminology
- -
-

So that the policies defined in the next sections are clear, we first - define some terms here.

-
-
Change
-
Any modification to LLVM including documentation, tests, build system, - etc. either in patch or - commit form.
-
Commit
-
A change submitted directly to LLVM software - repository via the cvs commit command.
-
Developer
-
Anyone who submits a change to LLVM.
-
Increment
-
A change or set of changes, whether by - patch or commit, that are - related by a single common purpose. Increments are atomic as they - leave LLVM in a stable state (both compiling and working properly).
-
Must
-
When used in a policy statement, the term must implies a - non-optional requirement on the developer.
-
Patch
-
A change submitted by email in patch (diff) - format generated by the cvs diff command.
-
Should
-
When used in a policy statement, the term should implies a - recommended but optional requirement on the developer.
-
-
- -
General Policies

This section contains policies that pertain generally to LLVM developers. -

LLVM Developers are expected to meet the following obligations in order + LLVM Developers are expected to meet the following obligations in order for LLVM to maintain a high standard of quality.

@@ -102,10 +68,11 @@
Stay Informed

Developers should stay informed by reading at least the - llvmdev email list. If you are doing - anything more than just casual work on LLVM, it is highly suggested that you - also subscribe to the llvm-commits list and pay attention to changes being - made by others.

+ llvmdev + email list. If you are doing anything more than just casual work on LLVM, + it is suggested that you also subscribe to the + llvm-commits + list and pay attention to changes being made by others.

We recommend that active developers register an email account with LLVM Bugzilla and preferably subscribe to the llvm-bugs @@ -123,14 +90,15 @@

  • keep the community informed about future changes to LLVM,
  • avoid duplication of effort by having multiple parties working on the same thing and not knowing about it, and
    • -
  • ensure that any issues around the proposed work are discussed and - resolved before any significant work is accomplished.
    • +
  • ensure that any technical issues around the proposed work are + discussed and resolved before any significant work is done.

    • The design of LLVM is carefully controlled to ensure that all the pieces fit together well. If you plan to make a major change to the way LLVM works or a major new extension, it is a good idea to get consensus with the development community before you start working on it.

    +
    Code Reviews
    @@ -138,7 +106,7 @@

    LLVM has a code review policy. Code review is an excellent way to ensure high quality in the software. The following policies apply:

      -
    1. All developers are required to have any significant changes reviewed +
    2. All developers are required to have significant changes reviewed before they are committed to the repository.
    3. Code reviews are conducted by email.
    4. Code can be reviewed either before it is committed or after.
      5. @@ -171,6 +139,7 @@ work (into a logical progression), simplifies code review and reduces the chance that you will get negative feedback on the change. Small increments also facilitate the maintenance of a high quality code base. +
    5. Larger increments require a larger testing effort.
    @@ -196,7 +165,7 @@
  • The change set should not cause performance or correctness regressions for the LLVM tools.
  • The changes should not cause performance or correctness regressions in - code compiled with LLVM on all applicable targets.
    • + code compiled by LLVM on all applicable targets. @@ -211,15 +180,16 @@ llvm/test directory. The appropriate sub-directory should be selected (see the Testing Guide for details). -
  • Test cases should be written in LLVM assembly language unless the +
  • Test cases should be written in + LLVM assembly language unless the feature or regression being tested requires another language (e.g. the bug being fixed or feature being implemented is in the lvm-gcc C++ front-end).
    • -
  • Test cases, especially for regressions, should be much as reduced as +
  • Test cases, especially for regressions, should be reduced as much as possible, by bugpoint or manually. It is unacceptable to place an entire failing program into llvm/test as this creates - a time-to-test burden on all developers. Keep them short!
    • + a time-to-test burden on all developers. Please keep them short.
  • More extensive test cases (applications, benchmarks, etc.) should be added to the llvm-test test suite. This test suite is for coverage not features or regressions.
    • @@ -256,7 +226,10 @@
  • The patch must compile against the CVS HEAD cleanly (zero warnings, zero errors).
  • All the llvm/test (Deja Gnu) tests must pass.
    • -
  • All the llvm-test tests must pass on at least one platform.
    • +
  • The patch should cause no regressions in the llvm-test test suite. How + much testing is appropriate depends on the nature of the patch. We leave it + to your good judgement, but you will be responsible for fixing any + regressions or reverting the patch.
    • @@ -278,15 +251,15 @@

    After a patch has been submitted, these policies apply:

      -
    1. The patch is subject to review by anyone on the llvm-commits email list. -
      2. +
    2. The patch is subject to review by anyone on the + llvm-commits + email list.
    3. Changes recommended by a reviewer should be incorporated into your - patch or you should explain why the reviewer is incorrect. This process - iterates until there are no more review comments.
      4. -
    4. If the submitter believes the review comment is in error, a response to - the - llvm-commits list should be made explaining why the recommendation - cannot be followed.
      5. + patch or you should explain why the reviewer is incorrect. +
    5. Changes to the patch must be re-submitted to the + llvm-commits + email list.
      6. +
    6. This process iterates until all review issues have been addressed.
    @@ -300,7 +273,7 @@
  • The patch submitter is responsible for all aspects of the patch per the quality policy above.
  • If the patch is discovered to not meet the - quality standards standards within a reasonable time + quality policy standards within a reasonable time frame (24 hours), it may be subject to reversal.
    • @@ -333,19 +306,19 @@
  • You are granted commit-after-approval to all parts of LLVM. To get approval, submit a patch to llvm-commits - per the patch policies above. When approved you may commit it - yourself.
    • + per the patch policies above. When approved you + may commit it yourself.
  • You are allowed to commit patches without approval which you think are obvious. This is clearly a subjective decision. We simply expect you to use good judgement.
    • -
  • You are granted commit-without-approval to those portions of LLVM - that you own (contributed) or maintain (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 reviewed after - they are committed.
    • +
  • You are allowed to commit patches without approval to those portions + of LLVM that you own (contributed) or maintain (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 + reviewed after they are committed.
  • Commits that violate the quality standards may be reverted. This is necessary when the change blocks other developers from - making progress. The developers is welcome to re-commit the change after + making progress. The developer is welcome to re-commit the change after the problem has been fixed.
  • Multiple violations of these policies or a single egregious violation may cause commit access to be revoked.
    • @@ -357,7 +330,8 @@

    We address here the issues of copyright and license for the LLVM project. - The object of the copyright and license is the LLVM source and documentation. + The object of the copyright and license is the LLVM source code and + documentation. Currently, the University of Illinois is the LLVM copyright holder and the terms of its license to LLVM users and developers is the University of @@ -366,7 +340,7 @@

    NOTE: This section deals with legal matters but does not provide legal - advice. It is intended only as a general guideline.

    + advice. It is intended only as a general guideline only.

    @@ -388,7 +362,7 @@
  • Developers should submit or commit patches to the CREDITS.txt file to summarize their contributions.
    • -
  • Commit comments should contain correct attribution of the person who s +
  • Commit comments should contain correct attribution of the person who submitted the patch if that person is not the committer (i.e. when a developer with commit privileges commits a patch for someone else).
    • @@ -398,7 +372,7 @@
    Copyright

    -

    However, for consistency and ease of management, the project requires the +

    For consistency and ease of management, the project requires the copyright for all LLVM software to be held by a single copyright holder. Although UIUC may assign the copyright of the software to another entity, the intent for the project is to always have a single entity hold the copy @@ -417,7 +391,8 @@ LLVM Oversight Group.

    The LLVM Oversight Group intends to keep LLVM perpetually open source and to use liberal open source licenses. The current license is the - University of Illinois Open Source License (see LICENSE.TXT), which boils + + University of Illinois/NCSA Open Source License, which boils down to this:

    + +
    Terminology
    + +
    +

    So that the policies defined in this document are clear, we define some + terms here.

    +
    +
    Change
    +
    Any modification to LLVM including documentation, tests, build system, + etc. either in patch or + commit form.
    +
    Commit
    +
    A change submitted directly to LLVM software + repository via the cvs commit command.
    +
    Developer
    +
    Anyone who submits a change to LLVM.
    +
    Increment
    +
    A change or set of changes, whether by + patch or commit, that are + related by a single common purpose. Increments are atomic as they + leave LLVM in a stable state (both compiling and working properly).
    +
    Must
    +
    When used in a policy statement, the term must implies a + non-optional requirement on the developer.
    +
    Patch
    +
    A change submitted by email in patch (diff) + format generated by the cvs diff command.
    +
    Should
    +
    When used in a policy statement, the term should implies a + recommended but optional requirement on the developer.
    +
    +
    +
    Policy Notes