I agree with Tim. This should be a stable document not one that needs frequent updates (which would only mean contributors would be expected to check it more often). Changes should be discussed/agreed first, thus using JIRA/svn would seem reasonable for this document.
-Mark. On 28 September 2006 at 10:46, Tim Ellison <[EMAIL PROTECTED]> wrote: > I'm not trying to be contrary - honest <g> - but I would suggest the > website. It is a reference document that doesn't need a collaboration > area on the wiki. The document has undergone review and should be > stable now. > > My 2c. > Tim > > Morozova, Nadezhda wrote: > > +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: harmony-dev@incubator.apache.org > > 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 === > >> > > > > > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > > --------------------------------------------------------------------- > 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]
