diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index 56f5b88edb4..1bf62f17aab 100644 --- a/docs/DeveloperPolicy.html +++ b/docs/DeveloperPolicy.html @@ -12,7 +12,8 @@
  • Introduction
  • General Policies
      -
    1. Stay Informed
      2. +
    2. Stay Informed
      3. +
    3. Making a Patch
    4. Code Reviews
    5. Test Cases
    6. Quality
      7. @@ -91,6 +92,37 @@ email list to keep track of bugs and enhancements occurring in LLVM.

      + +
      Making a Patch
      + +
      + +

      When making a patch for review, the goal is to make it as easy for the + reviewer to read it as possible. As such, we recommend that you:

      +
        +
      1. Make your patch against the CVS HEAD (main development trunk), + not a branch, and not an old version of LLVM. This makes it easy to + apply the patch.
        2. + +
      2. Similarly, patches should be submitted soon after they are generated. + Old patches may not apply correctly if the underlying code changes between + the time the patch was created and the time it is applied.
        3. + +
      3. Patches should be made with this command: + 
        cvs diff -Ntdup -5
        + or with the utility utils/mkpatch. to make it easy to read the + diff.
        4. + +
      4. Patches should not include differences in generated code such as the + code generated by flex, bison or tblgen. The + utils/mkpatch utility takes care of this for you.
        5. + +
      5. Contributions must not knowingly infringe on any patents. To the best of + our knowledge, LLVM is free of any existing patent violations and it is our + intent to keep it that way.
        6. +
      +
      +
      Code Reviews
      @@ -106,7 +138,9 @@ changes (or changes where the developer owns the component) can be reviewed after commit.
    7. The developer responsible for a code change is also responsible for - making all necessary review-related changes.
      8. + making all necessary review-related changes. +
    8. Code review can be an iterative process, which goes until all the patch + is ready to be committed.
    9. Developers should participate in code reviews as both a reviewer and a reviewee. We don't have a dedicated team of reviewers. If someone is kind enough to review your code, you should return the favor for someone @@ -325,81 +359,6 @@ Changes
      10. - -
      Patch Policies
      - - -
      -

      This section describes policies that apply to developers who regularly - contribute code to LLVM. As usual, we often accept small patches and - contributions that do not follow this policy. In this case, one of the - regular contributors has to get the code in shape.

      -
      - - -
      Patch Form
      -
      -

      When submitting a patch, developers must follow these rules:

      -
        -
      1. Patches must be made against the CVS HEAD (main development trunk), - not a branch.
        2. -
      2. Patches should be made with this command: - 
        cvs diff -Ntdup -5
        - or with the utility utils/mkpatch.
        3. -
      3. Patches should not include differences in generated code such as the - code generated by flex, bison or tblgen. The - utils/mkpatch utility takes care of this for you.
        4. -
      4. Contributions must not knowingly infringe on any patents. To the best of - our knowledge, LLVM is free of any existing patent violations and it is our - intent to keep it that way.
        5. -
      -
      - - -
      Patch Submission
      -
      -

      When a patch is ready to be submitted, these policies apply:

      -
        -
      1. Patches should be submitted immediately after they are generated. Stale - patches may not apply correctly if the underlying code changes between the - time the patch was created and the time it is applied.
        2. -
      2. Patches should be submitted by e-mail to the - - llvm-commits list.
        3. -
      -
      - - -
      After Submission
      -
      -

      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. Changes recommended by a reviewer should be incorporated into your - patch or you should explain why the reviewer is incorrect. -
      3. Changes to the patch must be re-submitted to the - llvm-commits - email list.
        4. -
      4. This process iterates until all review issues have been addressed.
        5. -
      -
      - - -
      After Commit
      -
      -

      After a patch has been committed, these policies apply:

      -
        -
      1. The patch is subject to further review by anyone on the llvm-commits - email list.
        2. -
      2. The patch submitter is responsible for all aspects of the patch per - the quality policy above.
        3. -
      3. If the patch is discovered to not meet the - quality policy standards within a reasonable time - frame (24 hours), it may be subject to reversal.
        4. -
      -
      Copyright and License