diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index b7548c95866..c3d364caed3 100644 --- a/docs/DeveloperPolicy.html +++ b/docs/DeveloperPolicy.html @@ -13,13 +13,15 @@
  • General Policies
    1. Stay Informed
    2. -
    3. Starting New Work
    4. Code Reviews
    5. Quality
    6. Test Cases
    7. Obtaining Commit Access
    8. -
    9. Incremental Development
    10. -
    11. Attribution
    12. +
    13. Making a Major Change +
        +
      1. Incremental Development
      2. +
    14. +
    15. Attribution of Changes
  • Patch Policies
      @@ -54,6 +56,13 @@
    1. Make life as simple and easy for contributors as possible.
    2. Keep the top of tree CVS/SVN trees as stable as possible.
    + +

    This policy is aimed at regular contributors to LLVM. People interested in + contributing one-off patches can do so in an informal way by sending them to + the + llvm-commits mailing list and engaging another developer to see it through + the process.

    + @@ -83,27 +92,6 @@ email list to keep track of bugs and enhancements occurring in LLVM.

    - -
    Starting New Work
    -
    -

    When a developer begins a major new project with the aim of contributing - it back to LLVM, s/he should inform the community with an email to - the llvm-dev - email list, to the extent possible. The reason for this is to: -

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

    The design of LLVM is carefully controlled to ensure that all the pieces - fit together well and are as consistent as possible. 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
    @@ -226,12 +214,35 @@ quality patches. If you would like commit access, please send an email to the
    -
    Incremental Development + +
    +

    When a developer begins a major new project with the aim of contributing + it back to LLVM, s/he should inform the community with an email to + the llvm-dev + email list, to the extent possible. The reason for this is to: +

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

    The design of LLVM is carefully controlled to ensure that all the pieces + fit together well and are as consistent as possible. 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.

    + +
    + + +
    -

    When making a large change to LLVM, we use a incremental style of - development instead of having long-term development branches. Long-term - development branches have a number of drawbacks:

    +

    Once the design of the new feature is finalized, the work itself should be + done as a series of incremental changes, not as a long-term development + branch. Long-term development branches have a number of drawbacks:

    1. Branches must have mainline merged into them periodically. If the branch @@ -281,7 +292,8 @@ quality patches. If you would like commit access, please send an email to the
    - +

    We believe in correct attribution of contributions to their contributors. However, we do not want the source code to be littered