From 1653fec412e8c365645262b41f27becc7aca1e29 Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Mon, 19 Feb 2007 05:57:29 +0000 Subject: refactor the top-level 'patches' section into a subsection of General Policies. Much of its content is now in other parts of the doc, and this brings it up immediately after 'stay informed' and right before 'code reviews'. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34406 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/DeveloperPolicy.html | 113 +++++++++++++++------------------------------- 1 file changed, 36 insertions(+), 77 deletions(-) (limited to 'docs/DeveloperPolicy.html') diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index 56f5b88edb..1bf62f17aa 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
      -- cgit v1.2.3