harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Date Thu, 14 Sep 2006 10:33:38 GMT
Thanks Alexey - I think these guidelines will be helpful for all of
us, whether opening, fixing or committing bugs and patches.
Just a couple of extra comments.

Alexey Petrenko 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.

1a. Provide plenty of information about steps necessary to recreate the 
bug. If
a patch for the fix has not been supplied, provide as much diagnostic 
about the failure as possible (stack trace, failure output, expected 
output etc.).

> 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.

We should also add a step here to say "add a comment to the JIRA
indicating that you are working on this bug", as suggested by Geir
at [1].



> 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?
> SY, Alexey
> 2006/9/13, Paulex Yang <paulex.yang@gmail.com>:
>> 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.

Oliver Deakin
IBM United Kingdom Limited

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message