Index: xdocs/get-involved.xml =================================================================== --- xdocs/get-involved.xml (revision 470126) +++ xdocs/get-involved.xml (working copy) @@ -57,7 +57,7 @@
- Here are some basic guidelines and suggestions : + Here are some basic guidelines and suggestions:
- Please use the subversion 'diff' utility to create a patch as follows : + Please use the subversion 'diff' utility to create a patch as follows:
svn diff file.java > file.patch
@@ -111,9 +111,100 @@
the project committers to review and possibly accept your patch.
-
+
+
+
+
+ A good issue requires cooperation of a reporter, a resolution provider,
+ and a committer. This section describes communication patters for
+ easy and painless issue resolution. If you couldn't follow any of these steps,
+ please add an explanatory comment to the issue.
+
+
+
+ If you are an issue reporter:
+
+ -
+ Provide maximum information about steps necessary to reproduce
+ the bug. Create as small test case as possible. A patch
+ which adds a test case to the Harmony test base is highly
+ appreciated.
+
+ -
+ Explicitly state the expected behavior and the
+ actual behavior of Harmony code, link to specs, RFCs, etc.
+
+ -
+ Dig out the issue yourself: provide as much diagnostic information
+ about the failure as possible (stack trace, failure output, expected output, etc),
+ link the issue to previous posts, JIRAs, RI bugs using full-text search,
+ and try to resolve the issue himself.
+
+ -
+ Verify the issue resolution when the patch is proposed and add a comment,
+ then he verify that commit has fixed the problem and add a comment.
+
+
+
+
+
+ If you are resolving non-bug difference, or invalid bug,
+ discuss the issue on the dev list and link it to the discussion thread. If you
+ are a committer, and you are convinced with results of the discussion, close the issue.
+
+
+
+ If you are a bug resolution provider:
+
+ -
+ Notify the community that you start investigation by adding
+ a comment to the issue and sending a message to the dev list. If you fail to
+ produce a patch, then add another comment with the results of your
+ investigation.
+
+ -
+ If a reporter doesn't provide a patch which contains a test, you
+ create a test yourself or write an appropriate comment explaining a reason why
+ the test cannot be created.
+
+ -
+ Any concerns? Discuss on the dev list. Any related discussions? Add a link to
+ the discussion as a comment.
+
+ -
+ All the patches should be realted to the trunk directory (directory
+ which contains COPYRIGHT, LICENSE, NOTICE, README.txt files). Test and fix
+ patches should be in different files. A class library and VM patches should
+ be attached to separate JIRA issues. If the patch requires to add, remove or
+ move some files in the repository, add the appropriate script.
+
+ -
+ Check that all unit and smoke tests pass for DRLVM. If it is an application-oriented issue, check the application.
+
+
+
+
+
+If you are to commit a bug fix:
+
+ -
+ If a test is available, add it. Check that the test fails. Apply the fix for the issue. Check that test succeeds now.
+
+ -
+ Check that all unit and smoke tests pass for DRLVM. If it is an application-oriented issue, check the application.
+
+ -
+ If there are problems on previous steps, post a comment to JIRA and let a resolution provider to resolve.
+
+ -
+ Otherwise commit a patch, add revision info into JIRA issue and make sure that the issue reporter is happy with the resolution.
+
+
+
+
+