harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Date Thu, 21 Sep 2006 13:41:20 GMT

On Sep 21, 2006, at 1:30 AM, 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.

I don't think that we'll be flooded, and I think that if we are we  
can change it.  I see the mail lists as the primary communication  
medium of the project.   By just encouraging people to comment in the  
JIRA, you are effectively establishing a parallel communications  
channel (remember, we've seen conversations happen entirely in JIRA).

Conversation among people expressing interest and others that are  
interested in watching or helping or such will happen easier if  
there's one place.  When people are annotating JIRAs and not  
mentioning anything to the dev list, I think those conversations  
won't happen, and we'll be poorer for it.

>
> 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.
>
> Anyway JIRA can be configured to send all the notifications to dev
> list if you think that this info will be useful for everybody.

I don't think we want all JIRA  notifications to go to the dev  
lists...  there was too much noise when we did that.

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


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