Index: guidelines.xml =================================================================== --- guidelines.xml (revision 472898) +++ guidelines.xml (working copy) @@ -278,12 +278,16 @@
-

Ideas must be review-then-commit; patches can be commit-then-review. -With a commit-then-review process, we trust that the developer doing the -commit has a high degree of confidence in the change. Doubtful changes, -new features, and large-scale overhauls need to be discussed before -being committed to a repository. Any major change -must receive consensus approval on the mailing list before being committed. +

+ Ideas must be review-then-commit; patches can be commit-then-review. + With a commit-then-review process, we trust that the developer doing the + commit has a high degree of confidence in the change. Doubtful changes, + new features, and large-scale overhauls need to be discussed before + being committed to a repository. Any major change + must receive consensus approval on the mailing list before being committed. + For detailed instructions on reporting, resolving and closing issues, refer to + + Good Issue Resolution Guideline.

Each developer is responsible for notifying the mailing list and Index: issue_resolution_guideline.xml =================================================================== --- issue_resolution_guideline.xml (revision 472898) +++ issue_resolution_guideline.xml (working copy) @@ -20,84 +20,82 @@ - Good Issue Resolution Guideline - Harmony Documentation Team + Good Issue Resolution Guideline + Harmony Documentation Team -

+

- This guideline covers a wide range of issues but not all of them. - If you cannot do one of the steps, then write a comment to the issue. + This guideline provides step-by-step instructions on reporting, resolving + and closing issues. If you cannot do one of the steps, then write a comment to the issue.

-

- Use your common sense! -

-
- -
-

+ +

    -
  1. Explicitly state the expected behavior and the
  2. - actual behavior of Harmony code. Use links to specs, rfcs, etc. -
  3. Try to create as small test case as possible. A patch - to test will be highly appreciated.
  4. -
  5. Provide max. information about steps necessary to recreate the bug. +
  6. State the expected behavior and the + actual behavior of Harmony code explicitly. Use links to + specifications, references, etc.
  7. +
  8. Create a test case as small as possible. A patch + to test is highly appreciated.
  9. +
  10. Provide maximum information about steps necessary to reproduce the bug. If a patch for the test has not been supplied, provide as much - diagnostic information about the failure as possible (stack trace, - failure output, expected output etc).
  11. -
  12. Remember to use issue links if applicable.
  13. -
  14. Check the issue resolution when it is committed. Add a comment.
  15. + diagnostic information about the failure as possible: stack trace, + failure output, expected output, etc. +
  16. Use issue links if applicable.
  17. +
  18. Check the issue resolution, when it is committed. Add a comment.
-

-
+ -
-

- Depending on the type of issue, do the following: -

    -
  1. - Issue is probably a non-bug difference, not a bug or invalid: + +

    To resolve an issue, define its type first.

    +

    + If the issue is a non-bug difference, not a bug or invalid, + you should do the following:

      -
    1. Discuss on the dev list.
    2. -
    3. Add a link to the discussion thread as a comment to issue.
    4. +
    5. Discuss the issue on the + developer mailing list.
    6. +
    7. Add a link to the discussion thread as a comment to the issue.
    -
  2. -
  3. - Issue is a bug: + +

    If the issue is a bug, you should do the following:

    :
      -
    1. Notify the community that you started investigation by adding - a comment to the issue and send a message to dev list. If you cannot - produce a patch, add another comment with the results of your investigation.
    2. +
    3. + Notify the community that you started investigation by adding + a comment to the issue and send a message to the + developer mailing list. + If you cannot create a patch, add another comment with your + investigation results.
    4. If reporter did not provide a patch to test: -
        -
      1. Try to create a patch to test.
      2. -
      3. If you cannot produce a patch, write a comment about it.
      4. -
      +
        +
      • Try to create one.
      • +
      • If you cannot create a patch, write a comment about it.
      • +
    5. -
    6. Create a patch to fix the issue. Any concerns? Discuss on the dev list. - Add a link to discussion as a comment.
    7. -
    8. All the pacthes (test and fix) should be relative to the directory where - the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk. - Or to the module root directory.
    9. +
    10. + Create a patch to fix the issue. If you have any questions, + discuss them on the developer mailing list. + Add a link to the discussion as a comment.
    11. +
    12. All pacthes, such as tests and fixes, should be relative to the directory where + the main build.xml is:
      + https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk,
      + or to the module root directory.
    13. Test and fix patches should be in different files.
    14. -
    15. If the patch requires to add, remove or move some files in the repository, add the appropriate script.
    16. +
    17. If the patch requires adding, removing or moving some files in the repository, + provide appropriate script.
    18. Check that all unit tests pass.
    19. -
    20. If it is an application-oriented issue, check the application.
    21. -
    22. Remember to use issue links if applicable.
    23. +
    24. If the issue is application-oriented, check the application.
    25. +
    26. Use issue links if applicable.
    -
  4. -
-

-
+ + -
+ +

To close an issue, define its type first.

- Depending on the issue type, do: -

    -
  1. Issue is a non-bug difference, not a bug or invalid: close the issue.
  2. -
  3. Issue is a bug: + If the issue is a non-bug difference, not a bug or invalid, you should close the issue.

    +

    If the issue is a bug, you should do the following:

    1. If a patch to test is available, apply it.
    2. Check that the test fails.
    3. @@ -105,14 +103,13 @@
    4. Check that test succeeds now.
    5. Make sure that all unit tests pass.
    6. For application-oriented issues, check the application.
    7. -
    8. If there are problems on previous steps, post a comment to - JIRA and let "resolution provider" to resolve.
    9. +
    10. If there are any problems on previous steps, post a comment to + JIRA and let "resolution provider" resolve them.
    11. Make sure that the issue reporter is happy with the resolution.
    12. -
    13. Add revision info into JIRA issue.
    14. +
    15. Add revision info into the JIRA issue.
    -
  4. -
-

-
+ + +
\ No newline at end of file Index: get-involved.xml =================================================================== --- get-involved.xml (revision 472898) +++ get-involved.xml (working copy) @@ -3,7 +3,7 @@ - Apache Harmony + How do I contribute, give feedback, fix bugs and so on? Harmony Documentation Team @@ -38,6 +38,10 @@ Bugs and other issues can be posted on the project JIRA +
  • Step-by-step instructions on reporting, resolving and closing issues are listed in + + Good Issue Resolution Guideline +
  • Additional documentation and discussion can be found on the project wiki