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 Fri, 15 Sep 2006 07:04:57 GMT

On 15 September 2006 at 12:18, "Vladimir Gorr" <vvgorr@gmail.com> wrote:
> 
> 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?

Yes.  But the patch metadata usually contains this information -
assuming people are using svn diff to create the diffs.

-Mark.

> 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
> >
> >
> 
> ------=_Part_22626_32452037.1158297490005--





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