+1 for Wiki. This is a more edit-friendly solution. I can also add a link to your Wiki page from the website - for people to know where to look for guidelines ;)
Best regards, Nadya Morozova -----Original Message----- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 11:21 AM To: [email protected] Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko <[EMAIL PROTECTED]>: > I've combined all the comments again. > > And here is the last version. I hope... :) > > === cut === > Preface > 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. > Use your common sense! > > Issue reporter: > 1. Explicitly state the expected behavior and the > actual behavior of Harmony code. Use links to specs, rfcs, etc. > 2. Try to create as small a test case as possible. A patch > to test will be highly appreciated. > 3. Provide max. information about steps necessary to recreate 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). > 4. Remember to use issue links if applicable. > 5. Check the issue resolution when it is committed. Add a comment. > > Resolution provider :) : > Depending on the type of issue, do the following: > > 1. Issue is probably a non-bug difference, not a bug or invalid: > 1.1. Discuss on the dev list. > 1.2. Add a link to the discussion thread as a comment to issue. > 2. Issue is a bug: > 2.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.2. If reporter did not provide a patch to test: > 2.2.1. Try to create a patch to test. > 2.2.2. If you cannot produce a patch, write a comment about it. > 2.3. Create a patch to fix the issue > 2.3.1. Any concerns? Discuss on the dev list. Add a link to > discussion as a comment. > 2.4. 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/tru nk. > Or to the module root directory. > 2.5. Test and fix patches should be in different files. > 2.6. If the patch requires to add, remove or move some files in the > repository, add the appropriate script. > 2.6. Check that all unit tests pass. > 2.8. If it is an application-oriented issue, check the application. > 2.9. Remember to use issue links if applicable. > > Committer: > Depending on the issue type, do: > 1. Issue is a non-bug difference, not a bug or invalid: > Close the issue. > 2. Issue is a bug: > 2.1. If a patch to test is available, apply it. > 2.2. Check that the test fails. > 2.3. Apply the fix for the issue. > 2.4. Check that test succeeds now. > 2.5. Make sure that all unit tests pass. > 2.6. For application-oriented issues, check the application. > 2.7. If there are problems on previous steps, post a comment to > JIRA and let "resolution provider" to resolve. > 2.8. Make sure that the issue reporter is happy with the resolution. > 2.9. Add revision info into JIRA issue > === cut === > -- Alexey A. Petrenko Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
