harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Date Thu, 21 Sep 2006 14:25:06 GMT
> 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.
...

Regards,



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


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


Mime
View raw message