harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Date Thu, 28 Sep 2006 07:21:14 GMT

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 :)


SY, Alexey

2006/9/26, Alexey Petrenko <alexey.a.petrenko@gmail.com>:
> 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/trunk.
> 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 ===

Alexey A. Petrenko
Intel Middleware Products Division

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