harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Date Thu, 14 Sep 2006 12:55:19 GMT

I'd suggest two further things.

First, we change the default JIRA priority to something lower than
'Major'.  Currently most come in as 'Major' even if they are trivial
edge cases that might never affect an application.  I assume because
people are just leaving the default unchanged without giving it much
thought.  If we change the default, then the guidelines could suggest
only raising the priority if the bug affects a real application.

Second, can we ask that all patches be relative to either the top-level
(where the main build.xml is) or modules/<module-name> (where a modules
build.xml is).  It bothers me when I see patches with files that
start with trunk/modules/... rather than trunk because I worry about
just how much these people are checking out.  At the other end of the
spectrum it takes much longer to apply a JIRA if, for example, I have to
change directory to modules/awt/src/test/api/java/common/java/awt/geom
to apply the test patch and then change directory
modules/awt/src/main/java/common/java/awt/geom to apply the fix.

Don't get me wrong though, I'm grateful for all bug reports and patches
but if we can make things a little more efficient then perhaps we might
get through them more quickly.

Regards,
 Mark.

On 14 September 2006 at 11:33, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> Thanks Alexey - I think these guidelines will be helpful for all of
> us, whether opening, fixing or committing bugs and patches.
> Just a couple of extra comments.
> 
> Alexey Petrenko wrote:
> > Guys,
> >
> > I think that we need to create something like "Good issue resolution
> > guideline" and post it on Harmony site or wiki. It will help community
> > to prepare good fixes and will help committers to spend less time on
> > applying other's patches.
> >
> > As a start we can take Nathan's post with additions from Paulex. I'll
> > add few points from me...
> >
> > Issue reporter:
> > 1. Reporter should try to create as small test case as possible. Patch
> > to test will be highly appreciated.
> 
> 1a. Provide plenty of information about steps necessary to recreate the 
> bug. If
> a patch for the fix has not been supplied, provide as much diagnostic 
> information
> about the failure as possible (stack trace, failure output, expected 
> output etc.).
> 
> > 2. Do not forget to use issue links if applicable.
> >
> > Resolution provider :) :
> > 1. Issue is probably a non-bug difference, not a bug or invalid:
> >    1.1. Discuss on dev-list.
> >    1.2. Add a link to the discussion thread as a comment to issue.
> > 2. Issue is a bug:
> >    2.1. If reporter did not provide patch to test:
> >        2.1.1. If it is possible to create a patch to test then create it.
> >        2.1.2. If it is not possible then note it in the comment.
> >    2.2. Create a patch to fix the issue
> >        2.2.1. Any concerns? Discuss on dev list. Add a link to
> > discussion as a comment.
> 
> We should also add a step here to say "add a comment to the JIRA
> indicating that you are working on this bug", as suggested by Geir
> at [1].
> 
> Regards,
> Oliver
> 
> [1] 
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/%3
> c45080599.1040500@pobox.com%3e
> 
> > 3. Do not forget to use issue links if applicable.
> >
> > Committer
> > 1. Issue is probably a non-bug difference, not a bug or invalid: close
> > the issue.
> > 2. Issue is a bug:
> >    2.1. Apply the patch to test if it exists.
> >    2.2. Check that test fails.
> >    2.3. Apply the fix for the issue
> >    2.4. Check that test does not fail any more
> >    2.5. If there is a problem on previous steps post a comment to
> > JIRA and let "resolution provider" to resolve.
> >
> > Thoughts? Comments? Additions?
> >
> > SY, Alexey
> >
> > 2006/9/13, Paulex Yang <paulex.yang@gmail.com>:
> >> Nathan Beyer wrote:
> >> > Here are a few things that I think might help with getting through 
> >> some of
> >> > the older outstanding issues, as well as new ones.
> >> >
> >> > * If an issue is old (over a month???), then verify that it's still 
> >> an issue
> >> > with the latest code and note this with a JIRA comment.
> >> > * Obviously posting patches is great, but patches without tests are 
> >> almost
> >> > always ignored.
> >> > ** If you're posting an enhancement, post a patch that enhances the 
> >> tests
> >> > and make sure they pass on an RI. (I always make sure the test 
> >> passes on the
> >> > RI before considering the patch.)
> >> > ** If you're posting a fix, post a patch that includes a regression 
> >> test. (I
> >> > always apply the test first, then run it to see it fail, then I 
> >> look at the
> >> > fix.)
> >> > * If there's a particular JIRA issue that you would like fixed and 
> >> a patch
> >> > already exists, try applying the patch yourself, verify it and then 
> >> add a
> >> > comment supporting the patch.
> >> >
> >> >
> >> > -Nathan
> >> +1 from me, this is an excellent guide. Only one more thing:
> >>
> >> * If the JIRA/patch is debatable for any reasons (non-bug difference,
> >> break others, any other concerns...), don't hesitate to forward it to
> >> dev-list for discussion.
> >>
> >> And further, if possible, I suggest to look at related JIRAs in one run,
> >> for example, there may be several issues/patches related to
> >> ObjectOutputStream, if you fixed/updated one, another patch may be
> >> outdated, a better way is to link them and consider them together.
> >
> 
> -- 
> Oliver Deakin
> IBM United Kingdom Limited
> 
> 
> ---------------------------------------------------------------------
> 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