harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Date Fri, 15 Sep 2006 11:39:44 GMT
Yes, I don't think it would hurt, even if it's in the patch as Mark noted.

geir


Vladimir Gorr wrote:
> On 9/15/06, Mark Hindess <mark.hindess@googlemail.com> wrote:
>>
>>
>> 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.
> 
> 
> Indeed someone of contributors can use another tool (say, GIT) to prepare
> their patches.
> It's a reason why I mentioned about the revision number.
> 
> Thanks,
> Vladimir.
> 
> 
> -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
>>
>>
> 

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