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:42:51 GMT
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


Mime
View raw message