harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Gorr" <vvg...@gmail.com>
Subject Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Date Fri, 15 Sep 2006 05:18:10 GMT
I'd like to add some words ...

IMO each contributor should be responsible his patch can be applied w/o any
problems.
That's why he should check these patches and run the tests before
filling new JIRA issue.
However nobody can guarantee either patch will be successfully applied later
due to the possible conflicts.
Therefore it'd be not bad to have a reference to the revision number
this patch has been created for.
I suppose it will lighten the work for committers. Does it make sense?

Thanks,
Vladimir.

On 9/14/06, Mark Hindess <mark.hindess@googlemail.com> wrote:
>
>
> Just thought of another item.  I've seen a patch recently where a move
> was encapsulated in the patch.  We should encourage contributions to
> supply recipes/scripts for "svn move" commands rather than non-atomic
> deletions and additions in patches.
>
> -Mark.
>
> On 14 September 2006 at 14:29, Mark Hindess <mark.hindess@googlemail.com>
> wrote:
> >
> > On 14 September 2006 at 17:13, "Alexey Petrenko" <
> alexey.a.petrenko@gmail.com
> > > wrote:
> > > Agree on both cases.
> > > We can also ask to use dos2unix utility on Windows to convert patches
> > > to unix LF fromat.
> >
> > I'm actually less worried about this one.  I tend to be able to get any
> > patch to work under linux using either dos2unix or using:
> >
> >   perl -pe '/^(Index|====|---|\+\+\+|\@\@)/&&s/\r//;'
> >
> > to remove the CR characters only from the metadata.  The latter will
> > become obsolete when we sort out the eol problems in svn.
> >
> > -Mark.
> >
> > > 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.co
> > m>
> > >  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
> communit
> > y
> > > > > > 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.
> Patc
> > h
> > > > > > 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
> >  i
> > > t.
> > > > > >        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.m
> > bo
> > > x/%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:
> clos
> > e
> > > > > > 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
> stil
> > l
> > > > > >> an issue
> > > > > >> > with the latest code and note this with a JIRA comment.
> > > > > >> > * Obviously posting patches is great, but patches without
> tests ar
> > e
> > > > > >> almost
> > > > > >> > always ignored.
> > > > > >> > ** If you're posting an enhancement, post a patch that
> enhances th
> > e
> > > > > >> 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
> regressio
> > n
> > > > > >> 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 the
> > n
> > > > > >> 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 t
> > o
> > > > > >> dev-list for discussion.
> > > > > >>
> > > > > >> And further, if possible, I suggest to look at related JIRAs
in
> one
> > ru
> > > n,
> > > > > >> 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
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message