Alexey Petrenko wrote: > 2006/9/20, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> I still don't think that people should only be notifying the >> community about indications of interest or such only in the JIRA. >> Sending mail to the dev list should also be in there. > Do we really need that? I'm afraid that dev list will be flooded by > the large number of small similar messages like "I'll try to prepare a > patch to issue #xxxx". And most of dev list readers will not be > interested in the most of this messages.
It's a low overhead to the dev list, and gives us all a sense of where work is progressing. If you see a mail with [classlib][regex] or whatever it may be a flag if you are already in that area. > From the other hand a man who is interested in particular issue can > easily check the issue state online or even subscribe to receive all > the issue changes in JIRA. And people who wants to receive all the > notification can subscribe to harmony-commits list. I'd actually like to see the link made the other way too, that is that mail referencing a HARMONY-XXX tag is linked to the JIRA issue comments page. > Anyway JIRA can be configured to send all the notifications to dev > list if you think that this info will be useful for everybody. It's already sent to the commit list -- that is fine. Regards, Tim >> Also, we should as people to name patch files as "HARMONY- >> <JIRA#>_whatever_.patch" It's very helpful. > Yes, this is useful. > It seems that most of the people are using this name pattern. > And adding this pattern to guideline is a good idea. > > SY, Alexey > >> On Sep 20, 2006, at 2:44 AM, Alexey Petrenko wrote: >> >> > I've combined all the ideas. And here is the result. >> > >> > === 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. 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/trunk >> > 2.5. 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.7. If it is an application-oriented issue, check the application. >> > 2.8. 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 >> > >> > --------------------------------------------------------------------- >> > 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] >> >> > > -- 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]
