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...
Excellent ;-) Only a few comments.
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.
0. Explicitly address: what is the expected behavior, and what's the
actual behavior of Harmony?
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 could also suggest some requirements for patch: e.g., avoid using
absolute path, provide a shell if necessary,
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
And make sure all tests pass ;-)
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 <[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]
--
Richard Liang
China 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]
