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, 14 Sep 2006 13:13:05 GMT
Agree on both cases.
We can also ask to use dos2unix utility on Windows to convert patches
to unix LF fromat.

SY, Alexey

2006/9/14, Mark Hindess <mark.hindess@googlemail.com>:
>
> 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
>
>


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