harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Date Thu, 21 Sep 2006 13:46:08 GMT
Alexey Petrenko wrote:
> 2006/9/20, Geir Magnusson Jr. <geir@pobox.com>:
>> 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: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

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


Mime
View raw message