From c7d954e9a9eec80d710c8260c9796d4e27d7dc1f Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Mon, 19 Feb 2007 05:43:04 +0000 Subject: [PATCH] Transmogrify 'Starting New Work' into 'Making a Major Change', add incremental development as a subsection of it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34403 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/DeveloperPolicy.html | 70 +++++++++++++++++++++++---------------- 1 file changed, 41 insertions(+), 29 deletions(-) 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. -
    2. Starting New Work
    3. Code Reviews
    4. Quality
    5. Test Cases
    6. Obtaining Commit Access
      7. -
    7. Incremental Development
      8. -
    8. Attribution
      9. +
    9. Making a Major Change +
        +
      1. Incremental Development
        2. +
      10. +
    10. 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. -
    2. avoid duplication of effort by having multiple parties working on the - same thing and not knowing about it, and
      3. -
    3. ensure that any technical issues around the proposed work are - discussed and resolved before any significant work is done.
      4. -
    -

    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 +
    Making a Major Change
    +
    +

    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. +
    2. avoid duplication of effort by having multiple parties working on the + same thing and not knowing about it, and
      3. +
    3. ensure that any technical issues around the proposed work are + discussed and resolved before any significant work is done.
      4. +
    + +

    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.

    + +
    + + +
    Incremental Development
    -

    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
    -
    Attribution
    +
    Attribution of +Changes

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