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:57:32 GMT

On Sep 21, 2006, at 9:42 AM, Tim Ellison wrote:

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

I think it makes it cleaner.  You can apply the test patch, w/o the  
code mods, and then run and show the tests fail.  THen apply the code  
patch, show that things get fixed.

geir

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