And the resolution provider should not forget to add a comment when he is starting development of the patch to prevent collisions. If the resolution provider is a committer he simply assigns the bug.
On 9/13/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
On 9/13/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote: > > Guys, > > I think that we need to create something like "Good issue resolution > guideline" and post it on Harmony site or wiki. It will help community > to prepare good fixes and will help committers to spend less time on > applying other's patches. > > As a start we can take Nathan's post with additions from Paulex. I'll > add few points from me... > > Issue reporter: > 1. Reporter should try to create as small test case as possible. Patch > to test will be highly appreciated. > 2. Do not forget to use issue links if applicable. > > Resolution provider :) : > 1. Issue is probably a non-bug difference, not a bug or invalid: > 1.1. Discuss on dev-list. > 1.2. Add a link to the discussion thread as a comment to issue. > 2. Issue is a bug: > 2.1. If reporter did not provide patch to test: > 2.1.1. If it is possible to create a patch to test then create it. > 2.1.2. If it is not possible then note it in the comment. > 2.2. Create a patch to fix the issue > 2.2.1. Any concerns? Discuss on dev list. Add a link to > discussion as a comment. > 3. Do not forget to use issue links if applicable. > > Committer > 1. Issue is probably a non-bug difference, not a bug or invalid: close > the issue. > 2. Issue is a bug: > 2.1. Apply the patch to test if it exists. > 2.2. Check that test fails. > 2.3. Apply the fix for the issue > 2.4. Check that test does not fail any more > 2.5. If there is a problem on previous steps post a comment to > JIRA and let "resolution provider" to resolve. > > Thoughts? Comments? Additions? Sounds excellent! SY, Alexey > > 2006/9/13, Paulex Yang <[EMAIL PROTECTED]>: > > Nathan Beyer wrote: > > > Here are a few things that I think might help with getting through > some of > > > the older outstanding issues, as well as new ones. > > > > > > * If an issue is old (over a month???), then verify that it's still an > issue > > > with the latest code and note this with a JIRA comment. > > > * Obviously posting patches is great, but patches without tests are > almost > > > always ignored. > > > ** If you're posting an enhancement, post a patch that enhances the > tests > > > and make sure they pass on an RI. (I always make sure the test passes > on the > > > RI before considering the patch.) > > > ** If you're posting a fix, post a patch that includes a regression > test. (I > > > always apply the test first, then run it to see it fail, then I look > at the > > > fix.) > > > * If there's a particular JIRA issue that you would like fixed and a > patch > > > already exists, try applying the patch yourself, verify it and then > add a > > > comment supporting the patch. > > > > > > > > > -Nathan > > +1 from me, this is an excellent guide. Only one more thing: > > > > * If the JIRA/patch is debatable for any reasons (non-bug difference, > > break others, any other concerns...), don't hesitate to forward it to > > dev-list for discussion. > > > > And further, if possible, I suggest to look at related JIRAs in one run, > > for example, there may be several issues/patches related to > > ObjectOutputStream, if you fixed/updated one, another patch may be > > outdated, a better way is to link them and consider them together. > > -- > 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] > > -- Andrew Zhang China Software Development Lab, IBM
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
