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:52:45 GMT
YES PLEASE :)

On Sep 21, 2006, at 6:37 AM, 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. :)
>
> Regards,
>
> 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
>> > > > > > >
>
>
> -- 
> Alexei Zakharov,
> Intel Middleware Product 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