diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index f3b2c70b35a..d2046e26afd 100644 --- a/docs/DeveloperPolicy.html +++ b/docs/DeveloperPolicy.html @@ -34,6 +34,7 @@
  • Copyright and License
      +
    1. Attribution
    2. Copyright
    3. License
    4. Developer Agreements
    5. @@ -184,11 +185,10 @@
    6. Code must compile cleanly (no errors, no warnings) on at least one platform.
    7. Code must pass the deja gnu (llvm/test) test suite.
    8. -

    Additionally, the committer is responsible for all of the following items. - It is considered significantly preferable for all of these items to be - accounted for before the code is submitted for review or committed.

    + The developer should ensure each of the following before the code is + submitted for review or committed.

    1. Code must compile cleanly on all platforms.
    2. Code must pass the llvm-test test suite including @@ -212,16 +212,17 @@ selected (see the Testing Guide for details).
    3. Test cases should be written in LLVM assembly language unless the - feature or regression being tested requires another language.
    4. -
    5. Test cases, especially for regressions, should be as reduced as - possible, preferably by - bugpoint. It is unacceptable + feature or regression being tested requires another language (e.g. the + but being fixed or feature being implemented is in the lvm-gcc C++ + front-end).
    6. +
    7. Test cases, especially for regressions, should be much as reduced as + possible, by bugpoint or + manually. It is unacceptable to place an entire failing program into llvm/test as this creates a time-to-test burden on all developers. Keep them short!
    8. More extensive test cases (applications, benchmarks, etc.) should be - added to the llvm-test test suite, after approval from the - Oversight Group. This test suite is for coverage not features or - regressions.
    9. + added to the llvm-test test suite. This test suite is for + coverage not features or regressions.
    @@ -239,9 +240,9 @@
    1. Patches must be made against the CVS HEAD (main development trunk), not a branch.
    2. -
    3. Patches must be made with this cvs command:
      +    
    4. Patches should be made with this command:
           cvs diff -Ntdup -5
      or with the utility utils/mkpatch.
    5. -
    6. Patches must not include differences in generated code such as the +
    7. 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.
    @@ -264,9 +265,9 @@

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

    1. Patches should be submitted immediately after they are generated. Stale - patches are unlikely to apply correctly and could be rejected simply due to - age.
    2. -
    3. Patches must be submitted by e-mail to the + patches may not apply correctly if the underlying code changes between the + time the patch was created and the time it is applied.
    4. +
    5. Patches should be submitted by e-mail to the llvm-commits list.
    @@ -279,8 +280,9 @@
    1. The patch is subject to review by anyone on the llvm-commits email list.
    2. -
    3. Any changes recommended by the reviewer must be made by the submitter - of the patch and the patch re-submitted.
    4. +
    5. Changes recommended by a reviewer should be incorporated into your + patch or you should explain why the reviewer is incorrect. This patch + iterates until there are no more review comments.
    6. If the submitter believes the review comment is in error, a response to the llvm-commits list should be made explaining why the recommendation @@ -310,14 +312,15 @@
      1. Commit access is not granted to anyone unless they specifically ask for it.
      2. -
      3. Requests for commit access must be sent to the LLVM Oversight Group at - oversight@llvm.org.
      4. +
      5. Requests for commit access must be sent to the + LLVM Oversight Group.
      6. Granting commit access is at the sole discretion of the LLVM Oversight Group.
      7. -
      8. Submitting patches to LLVM via the patch policy above will greatly - increase the chance that your request for commit access is granted.
      9. -
      10. Getting to know the members of the LLVM community (email, IRC, in person - contact, etc.) will also increase your chances.
      11. +
      +

      Submitting patches to LLVM via the patch policy above will greatly + increase the chance that your request for commit access is granted. Getting + to know the members of the LLVM community (email, IRC, in person contact, + etc.) will also increase your chances.

    @@ -328,8 +331,13 @@ apply:

    1. You are granted commit-after-approval to all parts of LLVM. - To get approval, submit a patch to llvm-commits per the patch policies - above. When approved you may commit it yourself.
    2. + To get approval, submit a patch to + llvm-commits + per the patch policies above. When approved you may commit it + yourself. +
    3. You are allowed to commit patches without approval which you think are + obvious. This is clearly a subjective decision. We simply expect you to + use good judgement.
    4. You are granted commit-without-approval to those portions of LLVM that you own (contributed) or maintain (have been assigned responsibility for), with the proviso that such commits must not break the build. This is @@ -340,8 +348,7 @@ making progress. The developers is welcome to re-commit the change after the problem has been fixed.
    5. Multiple violations of these policies or a single egregious violation - may cause commit access to be revoked, at the sole discretion of the - LLVM Oversight Group.
    6. + may cause commit access to be revoked.
    @@ -363,7 +370,7 @@ -
    Attribution
    +
    Attribution

    The LLVM project believes in correct attribution of contributions to their contributors, as follows:

    @@ -406,8 +413,8 @@

    LLVM licensing decisions will be made by the LLVM Oversight Group. Any - issues, comments or suggestions with the licensing should be sent to - oversight@llvm.org.

    + issues, comments or suggestions with the licensing should be sent to the + LLVM Oversight Group.

    The LLVM Oversight Group intends to keep LLVM perpetually open source and to use liberal open source licenses. The current license is the University of Illinois Open Source License (see LICENSE.TXT), which boils @@ -459,7 +466,8 @@ src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"> Valid HTML 4.01! - Written By: LLVM Oversight Group
    + Written By: the + LLVM Oversight Group
    The LLVM Compiler Infrastructure
    Last modified: $Date$