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 19:32:20 GMT

On Sep 21, 2006, at 3:27 PM, Tim Ellison wrote:

> Alexei Zakharov wrote:
>>> How does it help to attach them separately?
>>
>> Just to implement the algorithm for committers described earlier  
>> by Alexey:
>>
>> 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.
>> ...
>
> Pah, get yourself a decent patch tool and apply it selectively ;-)
>
> Seriously though, I don't care if the test and fix are separate or  
> combined.

I do.  what tool do you suggest?

>
> Regards,
> Tim
>
>
>> 2006/9/21, Tim Ellison <t.p.ellison@gmail.com>:
>>> Alexei Zakharov wrote:
>>>> Hi Alexey,
>>>>
>>>> IMHO it would be nice to explicitly state (for issue reports and/or
>>>> resolution providers) that patch to classlib code and patch to test
>>>> should be two separate patches. I personally posted several  
>>>> "combined"
>>>> patches in the past. :)
>>>
>>> My preference is for combined patches, if they come from the same
>>> contributor.
>>>
>>> How does it help to attach them separately?
>>>
>>> Regards,
>>> Tim
>>>
>>>
>>>> 2006/9/20, Alexey Petrenko <alexey.a.petrenko@gmail.com>:
>>>>> 2006/9/20, Mark Hindess <mark.hindess@googlemail.com>:
>>>>>>
>>>>>> Alexey,
>>>>>>
>>>>>> What was wrong with the initial suggestion of recommending  
>>>>>> patches
>>>>>> be either relative to the classlib/trunk or
>>>>>> classlib/trunk/module/<module-name>?
>>>>> Seems I was not very attentive...
>>>>> "Harmony root or module root" looks fine.
>>>>>
>>>>> Any other objections or corrections?
>>>>>
>>>>> SY, Alexey
>>>>>
>>>>>> I really don't care much *except* that there were two specific  
>>>>>> types
>>>>>> of patches I was trying to avoid as I mentioned when I first
>>> suggested
>>>>>> this guideline.  So I definitely think a guideline of some form
>>>>> would be
>>>>>> constructive.
>>>>>>
>>>>>> Regards,
>>>>>>  Mark.
>>>>>>
>>>>>> On 20 September 2006 at 15:48, "Alexey Petrenko"
>>>>> <alexey.a.petrenko@gmail.com> wrote:
>>>>>>> Then we should remove this requirement at all...
>>>>>>> Since it is possible to have a patches for a few modules at
>>> once. Or
>>>>>>> for a few modules and a doc.
>>>>>>>
>>>>>>> 2006/9/20, Mark Hindess <mark.hindess@googlemail.com>:
>>>>>>>>
>>>>>>>> On 20 September 2006 at 13:56, "Alexey Petrenko"
>>>>> <alexey.a.petrenko@gmail.c
>>>>>>> om> wrote:
>>>>>>>>> Not module build.xml but the main build.xml.
>>>>>>>>> Anyway since we got a lot of directories except of modules
>>> it is
>>>>>>>>> better to make a diff from the root.
>>>>>>>>
>>>>>>>> I anticipate that in time we will have people that only check
>>>>> out the
>>>>>>>> module they wish to work on.  So I'm happy to see patches
>>>>> relative to
>>>>>>>> a module's build.xml directory.
>>>>>>>>
>>>>>>>> -Mark.
>>>>>>>>
>>>>>>>>
>>>>>>>>> 2006/9/20, Oleg Khaschansky <oleg.v.khaschansky@gmail.com>:
>>>>>>>>>> 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/tr
>>>>>>> unk
>>>>>>>>>>
>>>>>>>>>> As Mark noted, the directory where the module's build.xml
is
>>>>> located
>>>>>>>>>> is also acceptable.
>>>>>>>>>>
>>>>>
>>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ 
>>> classlib/tr
>>>>>>> unk/
>>>>>>>>> modules/module_name
>>>>>>>>>> Generally, making the patch from this directory is
much
>>>>> faster then
>>>>>>>>>> from the classlib/trunk :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 9/20/06, Alexey Petrenko <alexey.a.petrenko@gmail.com>
>>>>> 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/
>>>>>>> trun
>>>>>>>>> k
>>>>>>>>>>>    2.5. If the patch requires to add, remove
or move some
>>>>> files in th
>>>>>>> e
>>>>>>>>>>> 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 resolutio
>>>>>>> n.
>>>>>>>>>>>    2.9. Add revision info into JIRA issue
>>
>>
>
> -- 
>
> 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
>


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