harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Date Thu, 21 Sep 2006 13:48:03 GMT
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?
There was an opinion that it is good to apply a test patch first and
make sure that it fails before the fix. And then make sure that it
does not fail any more.

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


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


Mime
View raw message