From: Chris Lattner Date: Mon, 19 Feb 2007 05:47:13 +0000 (+0000) Subject: remove terminology section (this is not a legal document) X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=39582bdd7bcb9c1375768e23d52202cc05e51182;p=oota-llvm.git remove terminology section (this is not a legal document) move testcases above quality. Mention that a testcase is part of quality. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34404 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index c3d364caed3..21848a86146 100644 --- a/docs/DeveloperPolicy.html +++ b/docs/DeveloperPolicy.html @@ -36,7 +36,6 @@
  • License
  • Developer Agreements
  • -
  • Terminology
  • Written by LLVM Oversight Team
    @@ -114,6 +113,33 @@ else. + + +
    Test Cases
    +
    +

    Developers are required to create test cases for any bugs fixed and any new + features added. The following policies apply:

    +
      +
    1. All feature and regression test cases must be added to the + llvm/test directory. The appropriate sub-directory should be + selected (see the Testing Guide for + details).
    2. +
    3. Test cases should be written in + LLVM assembly language unless the + feature or regression being tested requires another language (e.g. the + bug being fixed or feature being implemented is in the llvm-gcc C++ + front-end).
    4. +
    5. Test cases, especially for regressions, should be reduced as much 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. Please keep them short.
    6. +
    7. More extensive test cases (applications, benchmarks, etc.) should be + added to the llvm-test test suite. This test suite is for + coverage: not features or regressions.
    8. +
    +
    +
    Quality
    @@ -124,14 +150,17 @@ LLVM Coding Standards.
  • Code must compile cleanly (no errors, no warnings) on at least one platform.
  • -
  • Code must pass the deja gnu (llvm/test) test suite.
  • +
  • Bug fixes and new features should include a + testcase so we know if the fix/feature ever regresses in the + future.
  • +
  • Code must pass the dejagnu (llvm/test) test suite.
  • The code must not cause regressions on a reasonable subset of llvm-test, where "reasonable" depends on the contributor's judgement and the scope of the change (more invasive changes require more testing). A reasonable subset is "llvm-test/MultiSource/Benchmarks".
  • Additionally, the committer is responsible for addressing any problems - found that the change is responsible for. For example:

    + found in the future that the change is responsible for. For example:

    - -
    Test Cases
    -
    -

    Developers are required to create test cases for any bugs fixed and any new - features added. The following policies apply:

    -
      -
    1. All feature and regression test cases must be added to the - llvm/test directory. The appropriate sub-directory should be - selected (see the Testing Guide for - details).
    2. -
    3. Test cases should be written in - LLVM assembly language unless the - feature or regression being tested requires another language (e.g. the - bug being fixed or feature being implemented is in the llvm-gcc C++ - front-end).
    4. -
    5. Test cases, especially for regressions, should be reduced as much 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. Please keep them short.
    6. -
    7. More extensive test cases (applications, benchmarks, etc.) should be - added to the llvm-test test suite. This test suite is for - coverage: not features or regressions.
    8. -
    -
    -
    Obtaining Commit Access
    @@ -488,33 +491,6 @@ Changes
    - -
    Terminology
    - -
    -

    So that the policies defined in this document are clear, we define some - terms here.

    -
    -
    Change
    -
    Any modification to LLVM including documentation, tests, build system, - etc. either in patch or - commit form.
    -
    Commit
    -
    A change submitted directly to LLVM software - repository via the cvs commit command.
    -
    Developer
    -
    Anyone who submits a change to LLVM.
    -
    Increment
    -
    A change or set of changes, whether by - patch or commit, that are - related by a single common purpose. Increments are atomic as they - leave LLVM in a stable state (both compiling and working properly).
    -
    Patch
    -
    A change submitted by email in patch (diff) - format generated by the cvs diff command.
    -
    -
    -