From 1ff20cd47969f509aa791c862d9005a3fb0cf2f5 Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Mon, 19 Feb 2007 06:05:58 +0000 Subject: [PATCH] incremental changes to own section, protosection on patents git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34408 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/DeveloperPolicy.html | 40 ++++++++++++++++++++++++++-------------- 1 file changed, 26 insertions(+), 14 deletions(-) diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index e3e37f0bc1f..9bc6446a124 100644 --- a/docs/DeveloperPolicy.html +++ b/docs/DeveloperPolicy.html @@ -10,7 +10,7 @@
LLVM Developer Policy
  1. Introduction
  2. -
  3. General Policies +
  4. Developer Policies
    1. Stay Informed
    2. Making a Patch
    3. @@ -18,16 +18,15 @@
    4. Test Cases
    5. Quality
    6. Obtaining Commit Access
    7. -
    8. Making a Major Change -
        -
      1. Incremental Development
      2. -
    9. +
    10. Making a Major Change
    11. +
    12. Incremental Development
    13. Attribution of Changes
  5. Copyright and License
    1. Copyright
    2. License
    3. +
    4. Patents
    5. Developer Agreements
@@ -59,7 +58,7 @@ -
General Policies
+
Developer Policies

This section contains policies that pertain generally to regular LLVM @@ -103,16 +102,13 @@

  • Patches should be made with this command:
    cvs diff -Ntdup -5
    - or with the utility utils/mkpatch. to make it easy to read the + or with the utility utils/mkpatch, which makes it easy to read the diff.
  • 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.
  • -
  • 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.
  • @@ -265,15 +261,20 @@ quality patches. If you would like commit access, please send an email to the a major new extension, it is a good idea to get consensus with the development community before you start working on it.

    +

    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.

    + -
    Incremental Development +
    -

    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:

    +

    In the LLVM project, we do all significant changes as a series of + incremental patches. We have a strong dislike for huge changes or + long-term development branches. Long-term development branches have a + number of drawbacks:

    1. Branches must have mainline merged into them periodically. If the branch @@ -436,6 +437,17 @@ Changes
    href="mailto:llvm-oversight@cs.uiuc.edu">LLVM Oversight Group.

    + + +
    Patents
    +
    + +

    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.

    +
    + +
    Developer Agreements
    -- 2.11.0