You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/09/14 14:55:19 UTC
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
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 <ol...@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 <pa...@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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer
to supply patches for old JIRAs)
Posted by Tim Ellison <t....@gmail.com>.
Alexey Petrenko wrote:
> 2006/9/20, Geir Magnusson Jr. <ge...@pobox.com>:
>> I still don't think that people should only be notifying the
>> community about indications of interest or such only in the JIRA.
>> Sending mail to the dev list should also be in there.
> Do we really need that? I'm afraid that dev list will be flooded by
> the large number of small similar messages like "I'll try to prepare a
> patch to issue #xxxx". And most of dev list readers will not be
> interested in the most of this messages.
It's a low overhead to the dev list, and gives us all a sense of where
work is progressing. If you see a mail with [classlib][regex] or
whatever it may be a flag if you are already in that area.
> From the other hand a man who is interested in particular issue can
> easily check the issue state online or even subscribe to receive all
> the issue changes in JIRA. And people who wants to receive all the
> notification can subscribe to harmony-commits list.
I'd actually like to see the link made the other way too, that is that
mail referencing a HARMONY-XXX tag is linked to the JIRA issue comments
page.
> Anyway JIRA can be configured to send all the notifications to dev
> list if you think that this info will be useful for everybody.
It's already sent to the commit list -- that is fine.
Regards,
Tim
>> Also, we should as people to name patch files as "HARMONY-
>> <JIRA#>_whatever_.patch" It's very helpful.
> Yes, this is useful.
> It seems that most of the people are using this name pattern.
> And adding this pattern to guideline is a good idea.
>
> SY, Alexey
>
>> On Sep 20, 2006, at 2:44 AM, Alexey Petrenko wrote:
>>
>> > I've combined all the ideas. And here is the result.
>> >
>> > === cut ===
>> > Preface
>> > This guideline covers a wide range of issues but not all of them.
>> > If you cannot do one of the steps, then write a comment to the issue.
>> > Use your common sense!
>> >
>> > Issue reporter:
>> > 1. Explicitly state the expected behavior and the
>> > actual behavior of Harmony code. Use links to specs, rfcs, etc.
>> > 2. Try to create as small a test case as possible. A patch
>> > to test will be highly appreciated.
>> > 3. Provide max. information about steps necessary to recreate the bug.
>> > If a patch for the test has not been supplied, provide as much
>> > diagnostic information about the failure as possible (stack trace,
>> > failure output, expected output etc).
>> > 4. Remember to use issue links if applicable.
>> > 5. Check the issue resolution when it is committed. Add a comment.
>> >
>> > Resolution provider :) :
>> > Depending on the type of issue, do the following:
>> > 1. Issue is probably a non-bug difference, not a bug or invalid:
>> > 1.1. Discuss on the dev list.
>> > 1.2. Add a link to the discussion thread as a comment to issue.
>> > 2. Issue is a bug:
>> > 2.1. Notify the community that you started investigation by adding
>> > a comment to the issue. If you cannot produce a patch, add another
>> > comment with the results of your investigation.
>> > 2.2. If reporter did not provide a patch to test:
>> > 2.2.1. Try to create a patch to test.
>> > 2.2.2. If you cannot produce a patch, write a comment about it.
>> > 2.3. Create a patch to fix the issue
>> > 2.3.1. Any concerns? Discuss on the dev list. Add a link to
>> > discussion as a comment.
>> > 2.4. All the pacthes (test and fix) should be relative to the
>> > directory where the main build.xml is:
>> > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
>> > classlib/trunk
>> > 2.5. If the patch requires to add, remove or move some files in the
>> > repository, add the appropriate script.
>> > 2.6. Check that all unit tests pass.
>> > 2.7. If it is an application-oriented issue, check the application.
>> > 2.8. Remember to use issue links if applicable.
>> >
>> > Committer:
>> > Depending on the issue type, do:
>> > 1. Issue is a non-bug difference, not a bug or invalid:
>> > Close the issue.
>> > 2. Issue is a bug:
>> > 2.1. If a patch to test is available, apply it.
>> > 2.2. Check that the test fails.
>> > 2.3. Apply the fix for the issue.
>> > 2.4. Check that test succeeds now.
>> > 2.5. Make sure that all unit tests pass.
>> > 2.6. For application-oriented issues, check the application.
>> > 2.7. If there are problems on previous steps, post a comment to
>> > JIRA and let "resolution provider" to resolve.
>> > 2.8. Make sure that the issue reporter is happy with the resolution.
>> > 2.9. Add revision info into JIRA issue
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 21, 2006, at 1:30 AM, Alexey Petrenko wrote:
> 2006/9/20, Geir Magnusson Jr. <ge...@pobox.com>:
>> I still don't think that people should only be notifying the
>> community about indications of interest or such only in the JIRA.
>> Sending mail to the dev list should also be in there.
> Do we really need that? I'm afraid that dev list will be flooded by
> the large number of small similar messages like "I'll try to prepare a
> patch to issue #xxxx". And most of dev list readers will not be
> interested in the most of this messages.
I don't think that we'll be flooded, and I think that if we are we
can change it. I see the mail lists as the primary communication
medium of the project. By just encouraging people to comment in the
JIRA, you are effectively establishing a parallel communications
channel (remember, we've seen conversations happen entirely in JIRA).
Conversation among people expressing interest and others that are
interested in watching or helping or such will happen easier if
there's one place. When people are annotating JIRAs and not
mentioning anything to the dev list, I think those conversations
won't happen, and we'll be poorer for it.
>
> From the other hand a man who is interested in particular issue can
> easily check the issue state online or even subscribe to receive all
> the issue changes in JIRA.
> And people who wants to receive all the notification can subscribe to
> harmony-commits list.
>
> Anyway JIRA can be configured to send all the notifications to dev
> list if you think that this info will be useful for everybody.
I don't think we want all JIRA notifications to go to the dev
lists... there was too much noise when we did that.
>
>> Also, we should as people to name patch files as "HARMONY-
>> <JIRA#>_whatever_.patch" It's very helpful.
> Yes, this is useful.
> It seems that most of the people are using this name pattern.
> And adding this pattern to guideline is a good idea.
>
> SY, Alexey
>
>> On Sep 20, 2006, at 2:44 AM, Alexey Petrenko wrote:
>>
>> > I've combined all the ideas. And here is the result.
>> >
>> > === cut ===
>> > Preface
>> > This guideline covers a wide range of issues but not all of them.
>> > If you cannot do one of the steps, then write a comment to the
>> issue.
>> > Use your common sense!
>> >
>> > Issue reporter:
>> > 1. Explicitly state the expected behavior and the
>> > actual behavior of Harmony code. Use links to specs, rfcs, etc.
>> > 2. Try to create as small a test case as possible. A patch
>> > to test will be highly appreciated.
>> > 3. Provide max. information about steps necessary to recreate
>> the bug.
>> > If a patch for the test has not been supplied, provide as much
>> > diagnostic information about the failure as possible (stack trace,
>> > failure output, expected output etc).
>> > 4. Remember to use issue links if applicable.
>> > 5. Check the issue resolution when it is committed. Add a comment.
>> >
>> > Resolution provider :) :
>> > Depending on the type of issue, do the following:
>> > 1. Issue is probably a non-bug difference, not a bug or invalid:
>> > 1.1. Discuss on the dev list.
>> > 1.2. Add a link to the discussion thread as a comment to issue.
>> > 2. Issue is a bug:
>> > 2.1. Notify the community that you started investigation by
>> adding
>> > a comment to the issue. If you cannot produce a patch, add another
>> > comment with the results of your investigation.
>> > 2.2. If reporter did not provide a patch to test:
>> > 2.2.1. Try to create a patch to test.
>> > 2.2.2. If you cannot produce a patch, write a comment
>> about it.
>> > 2.3. Create a patch to fix the issue
>> > 2.3.1. Any concerns? Discuss on the dev list. Add a link to
>> > discussion as a comment.
>> > 2.4. All the pacthes (test and fix) should be relative to the
>> > directory where the main build.xml is:
>> > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
>> > classlib/trunk
>> > 2.5. If the patch requires to add, remove or move some files
>> in the
>> > repository, add the appropriate script.
>> > 2.6. Check that all unit tests pass.
>> > 2.7. If it is an application-oriented issue, check the
>> application.
>> > 2.8. Remember to use issue links if applicable.
>> >
>> > Committer:
>> > Depending on the issue type, do:
>> > 1. Issue is a non-bug difference, not a bug or invalid:
>> > Close the issue.
>> > 2. Issue is a bug:
>> > 2.1. If a patch to test is available, apply it.
>> > 2.2. Check that the test fails.
>> > 2.3. Apply the fix for the issue.
>> > 2.4. Check that test succeeds now.
>> > 2.5. Make sure that all unit tests pass.
>> > 2.6. For application-oriented issues, check the application.
>> > 2.7. If there are problems on previous steps, post a comment to
>> > JIRA and let "resolution provider" to resolve.
>> > 2.8. Make sure that the issue reporter is happy with the
>> resolution.
>> > 2.9. Add revision info into JIRA issue
>> >
>> >
>> ---------------------------------------------------------------------
>> > 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
2006/9/20, Geir Magnusson Jr. <ge...@pobox.com>:
> I still don't think that people should only be notifying the
> community about indications of interest or such only in the JIRA.
> Sending mail to the dev list should also be in there.
Do we really need that? I'm afraid that dev list will be flooded by
the large number of small similar messages like "I'll try to prepare a
patch to issue #xxxx". And most of dev list readers will not be
interested in the most of this messages.
>From the other hand a man who is interested in particular issue can
easily check the issue state online or even subscribe to receive all
the issue changes in JIRA.
And people who wants to receive all the notification can subscribe to
harmony-commits list.
Anyway JIRA can be configured to send all the notifications to dev
list if you think that this info will be useful for everybody.
> Also, we should as people to name patch files as "HARMONY-
> <JIRA#>_whatever_.patch" It's very helpful.
Yes, this is useful.
It seems that most of the people are using this name pattern.
And adding this pattern to guideline is a good idea.
SY, Alexey
> On Sep 20, 2006, at 2:44 AM, Alexey Petrenko wrote:
>
> > I've combined all the ideas. And here is the result.
> >
> > === cut ===
> > Preface
> > This guideline covers a wide range of issues but not all of them.
> > If you cannot do one of the steps, then write a comment to the issue.
> > Use your common sense!
> >
> > Issue reporter:
> > 1. Explicitly state the expected behavior and the
> > actual behavior of Harmony code. Use links to specs, rfcs, etc.
> > 2. Try to create as small a test case as possible. A patch
> > to test will be highly appreciated.
> > 3. Provide max. information about steps necessary to recreate the bug.
> > If a patch for the test has not been supplied, provide as much
> > diagnostic information about the failure as possible (stack trace,
> > failure output, expected output etc).
> > 4. Remember to use issue links if applicable.
> > 5. Check the issue resolution when it is committed. Add a comment.
> >
> > Resolution provider :) :
> > Depending on the type of issue, do the following:
> > 1. Issue is probably a non-bug difference, not a bug or invalid:
> > 1.1. Discuss on the dev list.
> > 1.2. Add a link to the discussion thread as a comment to issue.
> > 2. Issue is a bug:
> > 2.1. Notify the community that you started investigation by adding
> > a comment to the issue. If you cannot produce a patch, add another
> > comment with the results of your investigation.
> > 2.2. If reporter did not provide a patch to test:
> > 2.2.1. Try to create a patch to test.
> > 2.2.2. If you cannot produce a patch, write a comment about it.
> > 2.3. Create a patch to fix the issue
> > 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> > discussion as a comment.
> > 2.4. All the pacthes (test and fix) should be relative to the
> > directory where the main build.xml is:
> > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
> > classlib/trunk
> > 2.5. If the patch requires to add, remove or move some files in the
> > repository, add the appropriate script.
> > 2.6. Check that all unit tests pass.
> > 2.7. If it is an application-oriented issue, check the application.
> > 2.8. Remember to use issue links if applicable.
> >
> > Committer:
> > Depending on the issue type, do:
> > 1. Issue is a non-bug difference, not a bug or invalid:
> > Close the issue.
> > 2. Issue is a bug:
> > 2.1. If a patch to test is available, apply it.
> > 2.2. Check that the test fails.
> > 2.3. Apply the fix for the issue.
> > 2.4. Check that test succeeds now.
> > 2.5. Make sure that all unit tests pass.
> > 2.6. For application-oriented issues, check the application.
> > 2.7. If there are problems on previous steps, post a comment to
> > JIRA and let "resolution provider" to resolve.
> > 2.8. Make sure that the issue reporter is happy with the resolution.
> > 2.9. Add revision info into JIRA issue
> >
> > ---------------------------------------------------------------------
> > 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I still don't think that people should only be notifying the
community about indications of interest or such only in the JIRA.
Sending mail to the dev list should also be in there.
Also, we should as people to name patch files as "HARMONY-
<JIRA#>_whatever_.patch" It's very helpful.
On Sep 20, 2006, at 2:44 AM, Alexey Petrenko wrote:
> I've combined all the ideas. And here is the result.
>
> === cut ===
> Preface
> This guideline covers a wide range of issues but not all of them.
> If you cannot do one of the steps, then write a comment to the issue.
> Use your common sense!
>
> Issue reporter:
> 1. Explicitly state the expected behavior and the
> actual behavior of Harmony code. Use links to specs, rfcs, etc.
> 2. Try to create as small a test case as possible. A patch
> to test will be highly appreciated.
> 3. Provide max. information about steps necessary to recreate the bug.
> If a patch for the test has not been supplied, provide as much
> diagnostic information about the failure as possible (stack trace,
> failure output, expected output etc).
> 4. Remember to use issue links if applicable.
> 5. Check the issue resolution when it is committed. Add a comment.
>
> Resolution provider :) :
> Depending on the type of issue, do the following:
> 1. Issue is probably a non-bug difference, not a bug or invalid:
> 1.1. Discuss on the dev list.
> 1.2. Add a link to the discussion thread as a comment to issue.
> 2. Issue is a bug:
> 2.1. Notify the community that you started investigation by adding
> a comment to the issue. If you cannot produce a patch, add another
> comment with the results of your investigation.
> 2.2. If reporter did not provide a patch to test:
> 2.2.1. Try to create a patch to test.
> 2.2.2. If you cannot produce a patch, write a comment about it.
> 2.3. Create a patch to fix the issue
> 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> discussion as a comment.
> 2.4. All the pacthes (test and fix) should be relative to the
> directory where the main build.xml is:
> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
> classlib/trunk
> 2.5. If the patch requires to add, remove or move some files in the
> repository, add the appropriate script.
> 2.6. Check that all unit tests pass.
> 2.7. If it is an application-oriented issue, check the application.
> 2.8. Remember to use issue links if applicable.
>
> Committer:
> Depending on the issue type, do:
> 1. Issue is a non-bug difference, not a bug or invalid:
> Close the issue.
> 2. Issue is a bug:
> 2.1. If a patch to test is available, apply it.
> 2.2. Check that the test fails.
> 2.3. Apply the fix for the issue.
> 2.4. Check that test succeeds now.
> 2.5. Make sure that all unit tests pass.
> 2.6. For application-oriented issues, check the application.
> 2.7. If there are problems on previous steps, post a comment to
> JIRA and let "resolution provider" to resolve.
> 2.8. Make sure that the issue reporter is happy with the resolution.
> 2.9. Add revision info into JIRA issue
>
> ---------------------------------------------------------------------
> 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
2006/9/21, Tim Ellison <t....@gmail.com>:
> Alexei Zakharov wrote:
> > Hi Alexey,
> >
> > IMHO it would be nice to explicitly state (for issue reports and/or
> > resolution providers) that patch to classlib code and patch to test
> > should be two separate patches. I personally posted several "combined"
> > patches in the past. :)
>
> My preference is for combined patches, if they come from the same
> contributor.
>
> How does it help to attach them separately?
There was an opinion that it is good to apply a test patch first and
make sure that it fails before the fix. And then make sure that it
does not fail any more.
>
> Regards,
> Tim
>
>
> > 2006/9/20, Alexey Petrenko <al...@gmail.com>:
> >> 2006/9/20, Mark Hindess <ma...@googlemail.com>:
> >> >
> >> > Alexey,
> >> >
> >> > What was wrong with the initial suggestion of recommending patches
> >> > be either relative to the classlib/trunk or
> >> > classlib/trunk/module/<module-name>?
> >> Seems I was not very attentive...
> >> "Harmony root or module root" looks fine.
> >>
> >> Any other objections or corrections?
> >>
> >> SY, Alexey
> >>
> >> > I really don't care much *except* that there were two specific types
> >> > of patches I was trying to avoid as I mentioned when I first suggested
> >> > this guideline. So I definitely think a guideline of some form
> >> would be
> >> > constructive.
> >> >
> >> > Regards,
> >> > Mark.
> >> >
> >> > On 20 September 2006 at 15:48, "Alexey Petrenko"
> >> <al...@gmail.com> wrote:
> >> > > Then we should remove this requirement at all...
> >> > > Since it is possible to have a patches for a few modules at once. Or
> >> > > for a few modules and a doc.
> >> > >
> >> > > 2006/9/20, Mark Hindess <ma...@googlemail.com>:
> >> > > >
> >> > > > On 20 September 2006 at 13:56, "Alexey Petrenko"
> >> <alexey.a.petrenko@gmail.c
> >> > > om> wrote:
> >> > > > > Not module build.xml but the main build.xml.
> >> > > > > Anyway since we got a lot of directories except of modules it is
> >> > > > > better to make a diff from the root.
> >> > > >
> >> > > > I anticipate that in time we will have people that only check
> >> out the
> >> > > > module they wish to work on. So I'm happy to see patches
> >> relative to
> >> > > > a module's build.xml directory.
> >> > > >
> >> > > > -Mark.
> >> > > >
> >> > > >
> >> > > > > 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
> >> > > > > > 2.4. All the pacthes (test and fix) should be relative to the
> >> > > > > > directory where the main build.xml is:
> >> > > > > >
> >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> >> > > unk
> >> > > > > >
> >> > > > > > As Mark noted, the directory where the module's build.xml is
> >> located
> >> > > > > > is also acceptable.
> >> > > > > >
> >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> >> > > unk/
> >> > > > > modules/module_name
> >> > > > > > Generally, making the patch from this directory is much
> >> faster then
> >> > > > > > from the classlib/trunk :)
> >> > > > > >
> >> > > > > >
> >> > > > > > On 9/20/06, Alexey Petrenko <al...@gmail.com>
> >> wrote:
> >> > > > > > > I've combined all the ideas. And here is the result.
> >> > > > > > >
> >> > > > > > > === cut ===
> >> > > > > > > Preface
> >> > > > > > > This guideline covers a wide range of issues but not all
> >> of them.
> >> > > > > > > If you cannot do one of the steps, then write a comment to
> >> the issue.
> >> > > > > > > Use your common sense!
> >> > > > > > >
> >> > > > > > > Issue reporter:
> >> > > > > > > 1. Explicitly state the expected behavior and the
> >> > > > > > > actual behavior of Harmony code. Use links to specs, rfcs,
> >> etc.
> >> > > > > > > 2. Try to create as small a test case as possible. A patch
> >> > > > > > > to test will be highly appreciated.
> >> > > > > > > 3. Provide max. information about steps necessary to
> >> recreate the bug
> >> > > .
> >> > > > > > > If a patch for the test has not been supplied, provide as
> >> much
> >> > > > > > > diagnostic information about the failure as possible
> >> (stack trace,
> >> > > > > > > failure output, expected output etc).
> >> > > > > > > 4. Remember to use issue links if applicable.
> >> > > > > > > 5. Check the issue resolution when it is committed. Add a
> >> comment.
> >> > > > > > >
> >> > > > > > > Resolution provider :) :
> >> > > > > > > Depending on the type of issue, do the following:
> >> > > > > > > 1. Issue is probably a non-bug difference, not a bug or
> >> invalid:
> >> > > > > > > 1.1. Discuss on the dev list.
> >> > > > > > > 1.2. Add a link to the discussion thread as a comment
> >> to issue.
> >> > > > > > > 2. Issue is a bug:
> >> > > > > > > 2.1. Notify the community that you started
> >> investigation by adding
> >> > > > > > > a comment to the issue. If you cannot produce a patch, add
> >> another
> >> > > > > > > comment with the results of your investigation.
> >> > > > > > > 2.2. If reporter did not provide a patch to test:
> >> > > > > > > 2.2.1. Try to create a patch to test.
> >> > > > > > > 2.2.2. If you cannot produce a patch, write a
> >> comment about it
> >> > > .
> >> > > > > > > 2.3. Create a patch to fix the issue
> >> > > > > > > 2.3.1. Any concerns? Discuss on the dev list. Add a
> >> link to
> >> > > > > > > discussion as a comment.
> >> > > > > > > 2.4. All the pacthes (test and fix) should be relative
> >> to the
> >> > > > > > > directory where the main build.xml is:
> >> > > > > > >
> >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/
> >> > > trun
> >> > > > > k
> >> > > > > > > 2.5. If the patch requires to add, remove or move some
> >> files in th
> >> > > e
> >> > > > > > > repository, add the appropriate script.
> >> > > > > > > 2.6. Check that all unit tests pass.
> >> > > > > > > 2.7. If it is an application-oriented issue, check the
> >> application
> >> > > .
> >> > > > > > > 2.8. Remember to use issue links if applicable.
> >> > > > > > >
> >> > > > > > > Committer:
> >> > > > > > > Depending on the issue type, do:
> >> > > > > > > 1. Issue is a non-bug difference, not a bug or invalid:
> >> > > > > > > Close the issue.
> >> > > > > > > 2. Issue is a bug:
> >> > > > > > > 2.1. If a patch to test is available, apply it.
> >> > > > > > > 2.2. Check that the test fails.
> >> > > > > > > 2.3. Apply the fix for the issue.
> >> > > > > > > 2.4. Check that test succeeds now.
> >> > > > > > > 2.5. Make sure that all unit tests pass.
> >> > > > > > > 2.6. For application-oriented issues, check the
> >> application.
> >> > > > > > > 2.7. If there are problems on previous steps, post a
> >> comment to
> >> > > > > > > JIRA and let "resolution provider" to resolve.
> >> > > > > > > 2.8. Make sure that the issue reporter is happy with
> >> the resolutio
> >> > > n.
> >> > > > > > > 2.9. Add revision info into JIRA issue
> >> > > > > > >
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
I've published "Good issue resolution guideline" on Harmony site:
http://incubator.apache.org/harmony/issue_resolution_guideline.html
(wait for a while for the web site synchronization). It is not linked
to other pages yet.
So comments to guideline and link place suggestions are welcome.
SY, Alexey
2006/9/28, Geir Magnusson Jr. <ge...@pobox.com>:
>
> On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote:
>
> > Guys,
> >
> > Since there is no additional comments on this guideline...
> >
> > Let's put it somewhere.
> > We got two options: Harmony site and wiki.
> > I prefer wiki because it will be easy to edit it and I can put it
> > there myself :)
>
> And if you put in a patch for website, we can get it there too :) if
> you put in wiki, I'm going to take and put on site, so maybe save us
> some effort? (ok, save me the effort...)
>
> geir
>
> >
> > Thoughts?
> >
> > SY, Alexey
> >
> > 2006/9/26, Alexey Petrenko <al...@gmail.com>:
> >> I've combined all the comments again.
> >>
> >> And here is the last version. I hope... :)
> >>
> >> === cut ===
> >> Preface
> >> This guideline covers a wide range of issues but not all of them.
> >> If you cannot do one of the steps, then write a comment to the issue.
> >> Use your common sense!
> >>
> >> Issue reporter:
> >> 1. Explicitly state the expected behavior and the
> >> actual behavior of Harmony code. Use links to specs, rfcs, etc.
> >> 2. Try to create as small a test case as possible. A patch
> >> to test will be highly appreciated.
> >> 3. Provide max. information about steps necessary to recreate the
> >> bug.
> >> If a patch for the test has not been supplied, provide as much
> >> diagnostic information about the failure as possible (stack trace,
> >> failure output, expected output etc).
> >> 4. Remember to use issue links if applicable.
> >> 5. Check the issue resolution when it is committed. Add a comment.
> >>
> >> Resolution provider :) :
> >> Depending on the type of issue, do the following:
> >>
> >> 1. Issue is probably a non-bug difference, not a bug or invalid:
> >> 1.1. Discuss on the dev list.
> >> 1.2. Add a link to the discussion thread as a comment to issue.
> >> 2. Issue is a bug:
> >> 2.1. Notify the community that you started investigation by adding
> >> a comment to the issue and send a message to dev list. If you cannot
> >> produce a patch, add another comment with the results of your
> >> investigation.
> >> 2.2. If reporter did not provide a patch to test:
> >> 2.2.1. Try to create a patch to test.
> >> 2.2.2. If you cannot produce a patch, write a comment about it.
> >> 2.3. Create a patch to fix the issue
> >> 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> >> discussion as a comment.
> >> 2.4. All the pacthes (test and fix) should be relative to the
> >> directory where the main build.xml is:
> >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
> >> classlib/trunk.
> >> Or to the module root directory.
> >> 2.5. Test and fix patches should be in different files.
> >> 2.6. If the patch requires to add, remove or move some files in the
> >> repository, add the appropriate script.
> >> 2.6. Check that all unit tests pass.
> >> 2.8. If it is an application-oriented issue, check the application.
> >> 2.9. Remember to use issue links if applicable.
> >>
> >> Committer:
> >> Depending on the issue type, do:
> >> 1. Issue is a non-bug difference, not a bug or invalid:
> >> Close the issue.
> >> 2. Issue is a bug:
> >> 2.1. If a patch to test is available, apply it.
> >> 2.2. Check that the test fails.
> >> 2.3. Apply the fix for the issue.
> >> 2.4. Check that test succeeds now.
> >> 2.5. Make sure that all unit tests pass.
> >> 2.6. For application-oriented issues, check the application.
> >> 2.7. If there are problems on previous steps, post a comment to
> >> JIRA and let "resolution provider" to resolve.
> >> 2.8. Make sure that the issue reporter is happy with the
> >> resolution.
> >> 2.9. Add revision info into JIRA issue
> >> === cut ===
> >>
> >
> >
> > --
> > 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
>
>
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
:)
Yes, I'll prepare a patch.
2006/9/28, Geir Magnusson Jr. <ge...@pobox.com>:
>
> On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote:
>
> > Guys,
> >
> > Since there is no additional comments on this guideline...
> >
> > Let's put it somewhere.
> > We got two options: Harmony site and wiki.
> > I prefer wiki because it will be easy to edit it and I can put it
> > there myself :)
>
> And if you put in a patch for website, we can get it there too :) if
> you put in wiki, I'm going to take and put on site, so maybe save us
> some effort? (ok, save me the effort...)
>
> geir
>
> >
> > Thoughts?
> >
> > SY, Alexey
> >
> > 2006/9/26, Alexey Petrenko <al...@gmail.com>:
> >> I've combined all the comments again.
> >>
> >> And here is the last version. I hope... :)
> >>
> >> === cut ===
> >> Preface
> >> This guideline covers a wide range of issues but not all of them.
> >> If you cannot do one of the steps, then write a comment to the issue.
> >> Use your common sense!
> >>
> >> Issue reporter:
> >> 1. Explicitly state the expected behavior and the
> >> actual behavior of Harmony code. Use links to specs, rfcs, etc.
> >> 2. Try to create as small a test case as possible. A patch
> >> to test will be highly appreciated.
> >> 3. Provide max. information about steps necessary to recreate the
> >> bug.
> >> If a patch for the test has not been supplied, provide as much
> >> diagnostic information about the failure as possible (stack trace,
> >> failure output, expected output etc).
> >> 4. Remember to use issue links if applicable.
> >> 5. Check the issue resolution when it is committed. Add a comment.
> >>
> >> Resolution provider :) :
> >> Depending on the type of issue, do the following:
> >>
> >> 1. Issue is probably a non-bug difference, not a bug or invalid:
> >> 1.1. Discuss on the dev list.
> >> 1.2. Add a link to the discussion thread as a comment to issue.
> >> 2. Issue is a bug:
> >> 2.1. Notify the community that you started investigation by adding
> >> a comment to the issue and send a message to dev list. If you cannot
> >> produce a patch, add another comment with the results of your
> >> investigation.
> >> 2.2. If reporter did not provide a patch to test:
> >> 2.2.1. Try to create a patch to test.
> >> 2.2.2. If you cannot produce a patch, write a comment about it.
> >> 2.3. Create a patch to fix the issue
> >> 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> >> discussion as a comment.
> >> 2.4. All the pacthes (test and fix) should be relative to the
> >> directory where the main build.xml is:
> >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
> >> classlib/trunk.
> >> Or to the module root directory.
> >> 2.5. Test and fix patches should be in different files.
> >> 2.6. If the patch requires to add, remove or move some files in the
> >> repository, add the appropriate script.
> >> 2.6. Check that all unit tests pass.
> >> 2.8. If it is an application-oriented issue, check the application.
> >> 2.9. Remember to use issue links if applicable.
> >>
> >> Committer:
> >> Depending on the issue type, do:
> >> 1. Issue is a non-bug difference, not a bug or invalid:
> >> Close the issue.
> >> 2. Issue is a bug:
> >> 2.1. If a patch to test is available, apply it.
> >> 2.2. Check that the test fails.
> >> 2.3. Apply the fix for the issue.
> >> 2.4. Check that test succeeds now.
> >> 2.5. Make sure that all unit tests pass.
> >> 2.6. For application-oriented issues, check the application.
> >> 2.7. If there are problems on previous steps, post a comment to
> >> JIRA and let "resolution provider" to resolve.
> >> 2.8. Make sure that the issue reporter is happy with the
> >> resolution.
> >> 2.9. Add revision info into JIRA issue
> >> === cut ===
> >>
> >
> >
> > --
> > 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
>
>
--
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote:
> Guys,
>
> Since there is no additional comments on this guideline...
>
> Let's put it somewhere.
> We got two options: Harmony site and wiki.
> I prefer wiki because it will be easy to edit it and I can put it
> there myself :)
And if you put in a patch for website, we can get it there too :) if
you put in wiki, I'm going to take and put on site, so maybe save us
some effort? (ok, save me the effort...)
geir
>
> Thoughts?
>
> SY, Alexey
>
> 2006/9/26, Alexey Petrenko <al...@gmail.com>:
>> I've combined all the comments again.
>>
>> And here is the last version. I hope... :)
>>
>> === cut ===
>> Preface
>> This guideline covers a wide range of issues but not all of them.
>> If you cannot do one of the steps, then write a comment to the issue.
>> Use your common sense!
>>
>> Issue reporter:
>> 1. Explicitly state the expected behavior and the
>> actual behavior of Harmony code. Use links to specs, rfcs, etc.
>> 2. Try to create as small a test case as possible. A patch
>> to test will be highly appreciated.
>> 3. Provide max. information about steps necessary to recreate the
>> bug.
>> If a patch for the test has not been supplied, provide as much
>> diagnostic information about the failure as possible (stack trace,
>> failure output, expected output etc).
>> 4. Remember to use issue links if applicable.
>> 5. Check the issue resolution when it is committed. Add a comment.
>>
>> Resolution provider :) :
>> Depending on the type of issue, do the following:
>>
>> 1. Issue is probably a non-bug difference, not a bug or invalid:
>> 1.1. Discuss on the dev list.
>> 1.2. Add a link to the discussion thread as a comment to issue.
>> 2. Issue is a bug:
>> 2.1. Notify the community that you started investigation by adding
>> a comment to the issue and send a message to dev list. If you cannot
>> produce a patch, add another comment with the results of your
>> investigation.
>> 2.2. If reporter did not provide a patch to test:
>> 2.2.1. Try to create a patch to test.
>> 2.2.2. If you cannot produce a patch, write a comment about it.
>> 2.3. Create a patch to fix the issue
>> 2.3.1. Any concerns? Discuss on the dev list. Add a link to
>> discussion as a comment.
>> 2.4. All the pacthes (test and fix) should be relative to the
>> directory where the main build.xml is:
>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
>> classlib/trunk.
>> Or to the module root directory.
>> 2.5. Test and fix patches should be in different files.
>> 2.6. If the patch requires to add, remove or move some files in the
>> repository, add the appropriate script.
>> 2.6. Check that all unit tests pass.
>> 2.8. If it is an application-oriented issue, check the application.
>> 2.9. Remember to use issue links if applicable.
>>
>> Committer:
>> Depending on the issue type, do:
>> 1. Issue is a non-bug difference, not a bug or invalid:
>> Close the issue.
>> 2. Issue is a bug:
>> 2.1. If a patch to test is available, apply it.
>> 2.2. Check that the test fails.
>> 2.3. Apply the fix for the issue.
>> 2.4. Check that test succeeds now.
>> 2.5. Make sure that all unit tests pass.
>> 2.6. For application-oriented issues, check the application.
>> 2.7. If there are problems on previous steps, post a comment to
>> JIRA and let "resolution provider" to resolve.
>> 2.8. Make sure that the issue reporter is happy with the
>> resolution.
>> 2.9. Add revision info into JIRA issue
>> === cut ===
>>
>
>
> --
> 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
Guys,
Since there is no additional comments on this guideline...
Let's put it somewhere.
We got two options: Harmony site and wiki.
I prefer wiki because it will be easy to edit it and I can put it
there myself :)
Thoughts?
SY, Alexey
2006/9/26, Alexey Petrenko <al...@gmail.com>:
> I've combined all the comments again.
>
> And here is the last version. I hope... :)
>
> === cut ===
> Preface
> This guideline covers a wide range of issues but not all of them.
> If you cannot do one of the steps, then write a comment to the issue.
> Use your common sense!
>
> Issue reporter:
> 1. Explicitly state the expected behavior and the
> actual behavior of Harmony code. Use links to specs, rfcs, etc.
> 2. Try to create as small a test case as possible. A patch
> to test will be highly appreciated.
> 3. Provide max. information about steps necessary to recreate the bug.
> If a patch for the test has not been supplied, provide as much
> diagnostic information about the failure as possible (stack trace,
> failure output, expected output etc).
> 4. Remember to use issue links if applicable.
> 5. Check the issue resolution when it is committed. Add a comment.
>
> Resolution provider :) :
> Depending on the type of issue, do the following:
>
> 1. Issue is probably a non-bug difference, not a bug or invalid:
> 1.1. Discuss on the dev list.
> 1.2. Add a link to the discussion thread as a comment to issue.
> 2. Issue is a bug:
> 2.1. Notify the community that you started investigation by adding
> a comment to the issue and send a message to dev list. If you cannot
> produce a patch, add another comment with the results of your investigation.
> 2.2. If reporter did not provide a patch to test:
> 2.2.1. Try to create a patch to test.
> 2.2.2. If you cannot produce a patch, write a comment about it.
> 2.3. Create a patch to fix the issue
> 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> discussion as a comment.
> 2.4. All the pacthes (test and fix) should be relative to the
> directory where the main build.xml is:
> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk.
> Or to the module root directory.
> 2.5. Test and fix patches should be in different files.
> 2.6. If the patch requires to add, remove or move some files in the
> repository, add the appropriate script.
> 2.6. Check that all unit tests pass.
> 2.8. If it is an application-oriented issue, check the application.
> 2.9. Remember to use issue links if applicable.
>
> Committer:
> Depending on the issue type, do:
> 1. Issue is a non-bug difference, not a bug or invalid:
> Close the issue.
> 2. Issue is a bug:
> 2.1. If a patch to test is available, apply it.
> 2.2. Check that the test fails.
> 2.3. Apply the fix for the issue.
> 2.4. Check that test succeeds now.
> 2.5. Make sure that all unit tests pass.
> 2.6. For application-oriented issues, check the application.
> 2.7. If there are problems on previous steps, post a comment to
> JIRA and let "resolution provider" to resolve.
> 2.8. Make sure that the issue reporter is happy with the resolution.
> 2.9. Add revision info into JIRA issue
> === cut ===
>
--
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexei Zakharov <al...@gmail.com>.
This version looks good to me.
Regards,
2006/9/26, Alexey Petrenko <al...@gmail.com>:
> I've combined all the comments again.
>
> And here is the last version. I hope... :)
>
> === cut ===
> Preface
> This guideline covers a wide range of issues but not all of them.
> If you cannot do one of the steps, then write a comment to the issue.
> Use your common sense!
>
> Issue reporter:
> 1. Explicitly state the expected behavior and the
> actual behavior of Harmony code. Use links to specs, rfcs, etc.
> 2. Try to create as small a test case as possible. A patch
> to test will be highly appreciated.
> 3. Provide max. information about steps necessary to recreate the bug.
> If a patch for the test has not been supplied, provide as much
> diagnostic information about the failure as possible (stack trace,
> failure output, expected output etc).
> 4. Remember to use issue links if applicable.
> 5. Check the issue resolution when it is committed. Add a comment.
>
> Resolution provider :) :
> Depending on the type of issue, do the following:
>
> 1. Issue is probably a non-bug difference, not a bug or invalid:
> 1.1. Discuss on the dev list.
> 1.2. Add a link to the discussion thread as a comment to issue.
> 2. Issue is a bug:
> 2.1. Notify the community that you started investigation by adding
> a comment to the issue and send a message to dev list. If you cannot
> produce a patch, add another comment with the results of your investigation.
> 2.2. If reporter did not provide a patch to test:
> 2.2.1. Try to create a patch to test.
> 2.2.2. If you cannot produce a patch, write a comment about it.
> 2.3. Create a patch to fix the issue
> 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> discussion as a comment.
> 2.4. All the pacthes (test and fix) should be relative to the
> directory where the main build.xml is:
> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk.
> Or to the module root directory.
> 2.5. Test and fix patches should be in different files.
> 2.6. If the patch requires to add, remove or move some files in the
> repository, add the appropriate script.
> 2.6. Check that all unit tests pass.
> 2.8. If it is an application-oriented issue, check the application.
> 2.9. Remember to use issue links if applicable.
>
> Committer:
> Depending on the issue type, do:
> 1. Issue is a non-bug difference, not a bug or invalid:
> Close the issue.
> 2. Issue is a bug:
> 2.1. If a patch to test is available, apply it.
> 2.2. Check that the test fails.
> 2.3. Apply the fix for the issue.
> 2.4. Check that test succeeds now.
> 2.5. Make sure that all unit tests pass.
> 2.6. For application-oriented issues, check the application.
> 2.7. If there are problems on previous steps, post a comment to
> JIRA and let "resolution provider" to resolve.
> 2.8. Make sure that the issue reporter is happy with the resolution.
> 2.9. Add revision info into JIRA issue
> === cut ===
>
> ---------------------------------------------------------------------
> 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
>
>
--
Alexei Zakharov,
Intel Middleware Product 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
I've combined all the comments again.
And here is the last version. I hope... :)
=== cut ===
Preface
This guideline covers a wide range of issues but not all of them.
If you cannot do one of the steps, then write a comment to the issue.
Use your common sense!
Issue reporter:
1. Explicitly state the expected behavior and the
actual behavior of Harmony code. Use links to specs, rfcs, etc.
2. Try to create as small a test case as possible. A patch
to test will be highly appreciated.
3. Provide max. information about steps necessary to recreate the bug.
If a patch for the test has not been supplied, provide as much
diagnostic information about the failure as possible (stack trace,
failure output, expected output etc).
4. Remember to use issue links if applicable.
5. Check the issue resolution when it is committed. Add a comment.
Resolution provider :) :
Depending on the type of issue, do the following:
1. Issue is probably a non-bug difference, not a bug or invalid:
1.1. Discuss on the dev list.
1.2. Add a link to the discussion thread as a comment to issue.
2. Issue is a bug:
2.1. Notify the community that you started investigation by adding
a comment to the issue and send a message to dev list. If you cannot
produce a patch, add another comment with the results of your investigation.
2.2. If reporter did not provide a patch to test:
2.2.1. Try to create a patch to test.
2.2.2. If you cannot produce a patch, write a comment about it.
2.3. Create a patch to fix the issue
2.3.1. Any concerns? Discuss on the dev list. Add a link to
discussion as a comment.
2.4. All the pacthes (test and fix) should be relative to the
directory where the main build.xml is:
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk.
Or to the module root directory.
2.5. Test and fix patches should be in different files.
2.6. If the patch requires to add, remove or move some files in the
repository, add the appropriate script.
2.6. Check that all unit tests pass.
2.8. If it is an application-oriented issue, check the application.
2.9. Remember to use issue links if applicable.
Committer:
Depending on the issue type, do:
1. Issue is a non-bug difference, not a bug or invalid:
Close the issue.
2. Issue is a bug:
2.1. If a patch to test is available, apply it.
2.2. Check that the test fails.
2.3. Apply the fix for the issue.
2.4. Check that test succeeds now.
2.5. Make sure that all unit tests pass.
2.6. For application-oriented issues, check the application.
2.7. If there are problems on previous steps, post a comment to
JIRA and let "resolution provider" to resolve.
2.8. Make sure that the issue reporter is happy with the resolution.
2.9. Add revision info into JIRA issue
=== cut ===
---------------------------------------------------------------------
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer
to supply patches for old JIRAs)
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> I do. what tool do you suggest?
I use Eclipse and TortoiseSVN patch tools at different times. Both
allow you to read a combined patch, but update only a subset of affected
files.
Like I said though, I don't feel strongly so recommending separate
patches is ok by me if it helps others.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 21, 2006, at 3:27 PM, Tim Ellison wrote:
> Alexei Zakharov wrote:
>>> How does it help to attach them separately?
>>
>> Just to implement the algorithm for committers described earlier
>> by Alexey:
>>
>> 2. Issue is a bug:
>> 2.1. If a patch to test is available, apply it.
>> 2.2. Check that the test fails.
>> 2.3. Apply the fix for the issue.
>> 2.4. Check that test succeeds now.
>> 2.5. Make sure that all unit tests pass.
>> ...
>
> Pah, get yourself a decent patch tool and apply it selectively ;-)
>
> Seriously though, I don't care if the test and fix are separate or
> combined.
I do. what tool do you suggest?
>
> Regards,
> Tim
>
>
>> 2006/9/21, Tim Ellison <t....@gmail.com>:
>>> Alexei Zakharov wrote:
>>>> Hi Alexey,
>>>>
>>>> IMHO it would be nice to explicitly state (for issue reports and/or
>>>> resolution providers) that patch to classlib code and patch to test
>>>> should be two separate patches. I personally posted several
>>>> "combined"
>>>> patches in the past. :)
>>>
>>> My preference is for combined patches, if they come from the same
>>> contributor.
>>>
>>> How does it help to attach them separately?
>>>
>>> Regards,
>>> Tim
>>>
>>>
>>>> 2006/9/20, Alexey Petrenko <al...@gmail.com>:
>>>>> 2006/9/20, Mark Hindess <ma...@googlemail.com>:
>>>>>>
>>>>>> Alexey,
>>>>>>
>>>>>> What was wrong with the initial suggestion of recommending
>>>>>> patches
>>>>>> be either relative to the classlib/trunk or
>>>>>> classlib/trunk/module/<module-name>?
>>>>> Seems I was not very attentive...
>>>>> "Harmony root or module root" looks fine.
>>>>>
>>>>> Any other objections or corrections?
>>>>>
>>>>> SY, Alexey
>>>>>
>>>>>> I really don't care much *except* that there were two specific
>>>>>> types
>>>>>> of patches I was trying to avoid as I mentioned when I first
>>> suggested
>>>>>> this guideline. So I definitely think a guideline of some form
>>>>> would be
>>>>>> constructive.
>>>>>>
>>>>>> Regards,
>>>>>> Mark.
>>>>>>
>>>>>> On 20 September 2006 at 15:48, "Alexey Petrenko"
>>>>> <al...@gmail.com> wrote:
>>>>>>> Then we should remove this requirement at all...
>>>>>>> Since it is possible to have a patches for a few modules at
>>> once. Or
>>>>>>> for a few modules and a doc.
>>>>>>>
>>>>>>> 2006/9/20, Mark Hindess <ma...@googlemail.com>:
>>>>>>>>
>>>>>>>> On 20 September 2006 at 13:56, "Alexey Petrenko"
>>>>> <alexey.a.petrenko@gmail.c
>>>>>>> om> wrote:
>>>>>>>>> Not module build.xml but the main build.xml.
>>>>>>>>> Anyway since we got a lot of directories except of modules
>>> it is
>>>>>>>>> better to make a diff from the root.
>>>>>>>>
>>>>>>>> I anticipate that in time we will have people that only check
>>>>> out the
>>>>>>>> module they wish to work on. So I'm happy to see patches
>>>>> relative to
>>>>>>>> a module's build.xml directory.
>>>>>>>>
>>>>>>>> -Mark.
>>>>>>>>
>>>>>>>>
>>>>>>>>> 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
>>>>>>>>>> 2.4. All the pacthes (test and fix) should be relative to
>>> the
>>>>>>>>>> directory where the main build.xml is:
>>>>>>>>>>
>>>>>
>>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
>>> classlib/tr
>>>>>>> unk
>>>>>>>>>>
>>>>>>>>>> As Mark noted, the directory where the module's build.xml is
>>>>> located
>>>>>>>>>> is also acceptable.
>>>>>>>>>>
>>>>>
>>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
>>> classlib/tr
>>>>>>> unk/
>>>>>>>>> modules/module_name
>>>>>>>>>> Generally, making the patch from this directory is much
>>>>> faster then
>>>>>>>>>> from the classlib/trunk :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 9/20/06, Alexey Petrenko <al...@gmail.com>
>>>>> wrote:
>>>>>>>>>>> I've combined all the ideas. And here is the result.
>>>>>>>>>>>
>>>>>>>>>>> === cut ===
>>>>>>>>>>> Preface
>>>>>>>>>>> This guideline covers a wide range of issues but not all
>>>>> of them.
>>>>>>>>>>> If you cannot do one of the steps, then write a comment to
>>>>> the issue.
>>>>>>>>>>> Use your common sense!
>>>>>>>>>>>
>>>>>>>>>>> Issue reporter:
>>>>>>>>>>> 1. Explicitly state the expected behavior and the
>>>>>>>>>>> actual behavior of Harmony code. Use links to specs, rfcs,
>>>>> etc.
>>>>>>>>>>> 2. Try to create as small a test case as possible. A patch
>>>>>>>>>>> to test will be highly appreciated.
>>>>>>>>>>> 3. Provide max. information about steps necessary to
>>>>> recreate the bug
>>>>>>> .
>>>>>>>>>>> If a patch for the test has not been supplied, provide as
>>>>> much
>>>>>>>>>>> diagnostic information about the failure as possible
>>>>> (stack trace,
>>>>>>>>>>> failure output, expected output etc).
>>>>>>>>>>> 4. Remember to use issue links if applicable.
>>>>>>>>>>> 5. Check the issue resolution when it is committed. Add a
>>>>> comment.
>>>>>>>>>>>
>>>>>>>>>>> Resolution provider :) :
>>>>>>>>>>> Depending on the type of issue, do the following:
>>>>>>>>>>> 1. Issue is probably a non-bug difference, not a bug or
>>>>> invalid:
>>>>>>>>>>> 1.1. Discuss on the dev list.
>>>>>>>>>>> 1.2. Add a link to the discussion thread as a comment
>>>>> to issue.
>>>>>>>>>>> 2. Issue is a bug:
>>>>>>>>>>> 2.1. Notify the community that you started
>>>>> investigation by adding
>>>>>>>>>>> a comment to the issue. If you cannot produce a patch, add
>>>>> another
>>>>>>>>>>> comment with the results of your investigation.
>>>>>>>>>>> 2.2. If reporter did not provide a patch to test:
>>>>>>>>>>> 2.2.1. Try to create a patch to test.
>>>>>>>>>>> 2.2.2. If you cannot produce a patch, write a
>>>>> comment about it
>>>>>>> .
>>>>>>>>>>> 2.3. Create a patch to fix the issue
>>>>>>>>>>> 2.3.1. Any concerns? Discuss on the dev list. Add a
>>>>> link to
>>>>>>>>>>> discussion as a comment.
>>>>>>>>>>> 2.4. All the pacthes (test and fix) should be relative
>>>>> to the
>>>>>>>>>>> directory where the main build.xml is:
>>>>>>>>>>>
>>>>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
>>>>> classlib/
>>>>>>> trun
>>>>>>>>> k
>>>>>>>>>>> 2.5. If the patch requires to add, remove or move some
>>>>> files in th
>>>>>>> e
>>>>>>>>>>> repository, add the appropriate script.
>>>>>>>>>>> 2.6. Check that all unit tests pass.
>>>>>>>>>>> 2.7. If it is an application-oriented issue, check the
>>>>> application
>>>>>>> .
>>>>>>>>>>> 2.8. Remember to use issue links if applicable.
>>>>>>>>>>>
>>>>>>>>>>> Committer:
>>>>>>>>>>> Depending on the issue type, do:
>>>>>>>>>>> 1. Issue is a non-bug difference, not a bug or invalid:
>>>>>>>>>>> Close the issue.
>>>>>>>>>>> 2. Issue is a bug:
>>>>>>>>>>> 2.1. If a patch to test is available, apply it.
>>>>>>>>>>> 2.2. Check that the test fails.
>>>>>>>>>>> 2.3. Apply the fix for the issue.
>>>>>>>>>>> 2.4. Check that test succeeds now.
>>>>>>>>>>> 2.5. Make sure that all unit tests pass.
>>>>>>>>>>> 2.6. For application-oriented issues, check the
>>>>> application.
>>>>>>>>>>> 2.7. If there are problems on previous steps, post a
>>>>> comment to
>>>>>>>>>>> JIRA and let "resolution provider" to resolve.
>>>>>>>>>>> 2.8. Make sure that the issue reporter is happy with
>>>>> the resolutio
>>>>>>> n.
>>>>>>>>>>> 2.9. Add revision info into JIRA issue
>>
>>
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer
to supply patches for old JIRAs)
Posted by Tim Ellison <t....@gmail.com>.
Alexei Zakharov wrote:
>> How does it help to attach them separately?
>
> Just to implement the algorithm for committers described earlier by Alexey:
>
> 2. Issue is a bug:
> 2.1. If a patch to test is available, apply it.
> 2.2. Check that the test fails.
> 2.3. Apply the fix for the issue.
> 2.4. Check that test succeeds now.
> 2.5. Make sure that all unit tests pass.
> ...
Pah, get yourself a decent patch tool and apply it selectively ;-)
Seriously though, I don't care if the test and fix are separate or combined.
Regards,
Tim
> 2006/9/21, Tim Ellison <t....@gmail.com>:
>> Alexei Zakharov wrote:
>> > Hi Alexey,
>> >
>> > IMHO it would be nice to explicitly state (for issue reports and/or
>> > resolution providers) that patch to classlib code and patch to test
>> > should be two separate patches. I personally posted several "combined"
>> > patches in the past. :)
>>
>> My preference is for combined patches, if they come from the same
>> contributor.
>>
>> How does it help to attach them separately?
>>
>> Regards,
>> Tim
>>
>>
>> > 2006/9/20, Alexey Petrenko <al...@gmail.com>:
>> >> 2006/9/20, Mark Hindess <ma...@googlemail.com>:
>> >> >
>> >> > Alexey,
>> >> >
>> >> > What was wrong with the initial suggestion of recommending patches
>> >> > be either relative to the classlib/trunk or
>> >> > classlib/trunk/module/<module-name>?
>> >> Seems I was not very attentive...
>> >> "Harmony root or module root" looks fine.
>> >>
>> >> Any other objections or corrections?
>> >>
>> >> SY, Alexey
>> >>
>> >> > I really don't care much *except* that there were two specific types
>> >> > of patches I was trying to avoid as I mentioned when I first
>> suggested
>> >> > this guideline. So I definitely think a guideline of some form
>> >> would be
>> >> > constructive.
>> >> >
>> >> > Regards,
>> >> > Mark.
>> >> >
>> >> > On 20 September 2006 at 15:48, "Alexey Petrenko"
>> >> <al...@gmail.com> wrote:
>> >> > > Then we should remove this requirement at all...
>> >> > > Since it is possible to have a patches for a few modules at
>> once. Or
>> >> > > for a few modules and a doc.
>> >> > >
>> >> > > 2006/9/20, Mark Hindess <ma...@googlemail.com>:
>> >> > > >
>> >> > > > On 20 September 2006 at 13:56, "Alexey Petrenko"
>> >> <alexey.a.petrenko@gmail.c
>> >> > > om> wrote:
>> >> > > > > Not module build.xml but the main build.xml.
>> >> > > > > Anyway since we got a lot of directories except of modules
>> it is
>> >> > > > > better to make a diff from the root.
>> >> > > >
>> >> > > > I anticipate that in time we will have people that only check
>> >> out the
>> >> > > > module they wish to work on. So I'm happy to see patches
>> >> relative to
>> >> > > > a module's build.xml directory.
>> >> > > >
>> >> > > > -Mark.
>> >> > > >
>> >> > > >
>> >> > > > > 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
>> >> > > > > > 2.4. All the pacthes (test and fix) should be relative to
>> the
>> >> > > > > > directory where the main build.xml is:
>> >> > > > > >
>> >>
>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
>> >> > > unk
>> >> > > > > >
>> >> > > > > > As Mark noted, the directory where the module's build.xml is
>> >> located
>> >> > > > > > is also acceptable.
>> >> > > > > >
>> >>
>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
>> >> > > unk/
>> >> > > > > modules/module_name
>> >> > > > > > Generally, making the patch from this directory is much
>> >> faster then
>> >> > > > > > from the classlib/trunk :)
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > On 9/20/06, Alexey Petrenko <al...@gmail.com>
>> >> wrote:
>> >> > > > > > > I've combined all the ideas. And here is the result.
>> >> > > > > > >
>> >> > > > > > > === cut ===
>> >> > > > > > > Preface
>> >> > > > > > > This guideline covers a wide range of issues but not all
>> >> of them.
>> >> > > > > > > If you cannot do one of the steps, then write a comment to
>> >> the issue.
>> >> > > > > > > Use your common sense!
>> >> > > > > > >
>> >> > > > > > > Issue reporter:
>> >> > > > > > > 1. Explicitly state the expected behavior and the
>> >> > > > > > > actual behavior of Harmony code. Use links to specs, rfcs,
>> >> etc.
>> >> > > > > > > 2. Try to create as small a test case as possible. A patch
>> >> > > > > > > to test will be highly appreciated.
>> >> > > > > > > 3. Provide max. information about steps necessary to
>> >> recreate the bug
>> >> > > .
>> >> > > > > > > If a patch for the test has not been supplied, provide as
>> >> much
>> >> > > > > > > diagnostic information about the failure as possible
>> >> (stack trace,
>> >> > > > > > > failure output, expected output etc).
>> >> > > > > > > 4. Remember to use issue links if applicable.
>> >> > > > > > > 5. Check the issue resolution when it is committed. Add a
>> >> comment.
>> >> > > > > > >
>> >> > > > > > > Resolution provider :) :
>> >> > > > > > > Depending on the type of issue, do the following:
>> >> > > > > > > 1. Issue is probably a non-bug difference, not a bug or
>> >> invalid:
>> >> > > > > > > 1.1. Discuss on the dev list.
>> >> > > > > > > 1.2. Add a link to the discussion thread as a comment
>> >> to issue.
>> >> > > > > > > 2. Issue is a bug:
>> >> > > > > > > 2.1. Notify the community that you started
>> >> investigation by adding
>> >> > > > > > > a comment to the issue. If you cannot produce a patch, add
>> >> another
>> >> > > > > > > comment with the results of your investigation.
>> >> > > > > > > 2.2. If reporter did not provide a patch to test:
>> >> > > > > > > 2.2.1. Try to create a patch to test.
>> >> > > > > > > 2.2.2. If you cannot produce a patch, write a
>> >> comment about it
>> >> > > .
>> >> > > > > > > 2.3. Create a patch to fix the issue
>> >> > > > > > > 2.3.1. Any concerns? Discuss on the dev list. Add a
>> >> link to
>> >> > > > > > > discussion as a comment.
>> >> > > > > > > 2.4. All the pacthes (test and fix) should be relative
>> >> to the
>> >> > > > > > > directory where the main build.xml is:
>> >> > > > > > >
>> >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/
>> >> > > trun
>> >> > > > > k
>> >> > > > > > > 2.5. If the patch requires to add, remove or move some
>> >> files in th
>> >> > > e
>> >> > > > > > > repository, add the appropriate script.
>> >> > > > > > > 2.6. Check that all unit tests pass.
>> >> > > > > > > 2.7. If it is an application-oriented issue, check the
>> >> application
>> >> > > .
>> >> > > > > > > 2.8. Remember to use issue links if applicable.
>> >> > > > > > >
>> >> > > > > > > Committer:
>> >> > > > > > > Depending on the issue type, do:
>> >> > > > > > > 1. Issue is a non-bug difference, not a bug or invalid:
>> >> > > > > > > Close the issue.
>> >> > > > > > > 2. Issue is a bug:
>> >> > > > > > > 2.1. If a patch to test is available, apply it.
>> >> > > > > > > 2.2. Check that the test fails.
>> >> > > > > > > 2.3. Apply the fix for the issue.
>> >> > > > > > > 2.4. Check that test succeeds now.
>> >> > > > > > > 2.5. Make sure that all unit tests pass.
>> >> > > > > > > 2.6. For application-oriented issues, check the
>> >> application.
>> >> > > > > > > 2.7. If there are problems on previous steps, post a
>> >> comment to
>> >> > > > > > > JIRA and let "resolution provider" to resolve.
>> >> > > > > > > 2.8. Make sure that the issue reporter is happy with
>> >> the resolutio
>> >> > > n.
>> >> > > > > > > 2.9. Add revision info into JIRA issue
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexei Zakharov <al...@gmail.com>.
> How does it help to attach them separately?
Just to implement the algorithm for committers described earlier by Alexey:
2. Issue is a bug:
2.1. If a patch to test is available, apply it.
2.2. Check that the test fails.
2.3. Apply the fix for the issue.
2.4. Check that test succeeds now.
2.5. Make sure that all unit tests pass.
...
Regards,
2006/9/21, Tim Ellison <t....@gmail.com>:
> Alexei Zakharov wrote:
> > Hi Alexey,
> >
> > IMHO it would be nice to explicitly state (for issue reports and/or
> > resolution providers) that patch to classlib code and patch to test
> > should be two separate patches. I personally posted several "combined"
> > patches in the past. :)
>
> My preference is for combined patches, if they come from the same
> contributor.
>
> How does it help to attach them separately?
>
> Regards,
> Tim
>
>
> > 2006/9/20, Alexey Petrenko <al...@gmail.com>:
> >> 2006/9/20, Mark Hindess <ma...@googlemail.com>:
> >> >
> >> > Alexey,
> >> >
> >> > What was wrong with the initial suggestion of recommending patches
> >> > be either relative to the classlib/trunk or
> >> > classlib/trunk/module/<module-name>?
> >> Seems I was not very attentive...
> >> "Harmony root or module root" looks fine.
> >>
> >> Any other objections or corrections?
> >>
> >> SY, Alexey
> >>
> >> > I really don't care much *except* that there were two specific types
> >> > of patches I was trying to avoid as I mentioned when I first suggested
> >> > this guideline. So I definitely think a guideline of some form
> >> would be
> >> > constructive.
> >> >
> >> > Regards,
> >> > Mark.
> >> >
> >> > On 20 September 2006 at 15:48, "Alexey Petrenko"
> >> <al...@gmail.com> wrote:
> >> > > Then we should remove this requirement at all...
> >> > > Since it is possible to have a patches for a few modules at once. Or
> >> > > for a few modules and a doc.
> >> > >
> >> > > 2006/9/20, Mark Hindess <ma...@googlemail.com>:
> >> > > >
> >> > > > On 20 September 2006 at 13:56, "Alexey Petrenko"
> >> <alexey.a.petrenko@gmail.c
> >> > > om> wrote:
> >> > > > > Not module build.xml but the main build.xml.
> >> > > > > Anyway since we got a lot of directories except of modules it is
> >> > > > > better to make a diff from the root.
> >> > > >
> >> > > > I anticipate that in time we will have people that only check
> >> out the
> >> > > > module they wish to work on. So I'm happy to see patches
> >> relative to
> >> > > > a module's build.xml directory.
> >> > > >
> >> > > > -Mark.
> >> > > >
> >> > > >
> >> > > > > 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
> >> > > > > > 2.4. All the pacthes (test and fix) should be relative to the
> >> > > > > > directory where the main build.xml is:
> >> > > > > >
> >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> >> > > unk
> >> > > > > >
> >> > > > > > As Mark noted, the directory where the module's build.xml is
> >> located
> >> > > > > > is also acceptable.
> >> > > > > >
> >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> >> > > unk/
> >> > > > > modules/module_name
> >> > > > > > Generally, making the patch from this directory is much
> >> faster then
> >> > > > > > from the classlib/trunk :)
> >> > > > > >
> >> > > > > >
> >> > > > > > On 9/20/06, Alexey Petrenko <al...@gmail.com>
> >> wrote:
> >> > > > > > > I've combined all the ideas. And here is the result.
> >> > > > > > >
> >> > > > > > > === cut ===
> >> > > > > > > Preface
> >> > > > > > > This guideline covers a wide range of issues but not all
> >> of them.
> >> > > > > > > If you cannot do one of the steps, then write a comment to
> >> the issue.
> >> > > > > > > Use your common sense!
> >> > > > > > >
> >> > > > > > > Issue reporter:
> >> > > > > > > 1. Explicitly state the expected behavior and the
> >> > > > > > > actual behavior of Harmony code. Use links to specs, rfcs,
> >> etc.
> >> > > > > > > 2. Try to create as small a test case as possible. A patch
> >> > > > > > > to test will be highly appreciated.
> >> > > > > > > 3. Provide max. information about steps necessary to
> >> recreate the bug
> >> > > .
> >> > > > > > > If a patch for the test has not been supplied, provide as
> >> much
> >> > > > > > > diagnostic information about the failure as possible
> >> (stack trace,
> >> > > > > > > failure output, expected output etc).
> >> > > > > > > 4. Remember to use issue links if applicable.
> >> > > > > > > 5. Check the issue resolution when it is committed. Add a
> >> comment.
> >> > > > > > >
> >> > > > > > > Resolution provider :) :
> >> > > > > > > Depending on the type of issue, do the following:
> >> > > > > > > 1. Issue is probably a non-bug difference, not a bug or
> >> invalid:
> >> > > > > > > 1.1. Discuss on the dev list.
> >> > > > > > > 1.2. Add a link to the discussion thread as a comment
> >> to issue.
> >> > > > > > > 2. Issue is a bug:
> >> > > > > > > 2.1. Notify the community that you started
> >> investigation by adding
> >> > > > > > > a comment to the issue. If you cannot produce a patch, add
> >> another
> >> > > > > > > comment with the results of your investigation.
> >> > > > > > > 2.2. If reporter did not provide a patch to test:
> >> > > > > > > 2.2.1. Try to create a patch to test.
> >> > > > > > > 2.2.2. If you cannot produce a patch, write a
> >> comment about it
> >> > > .
> >> > > > > > > 2.3. Create a patch to fix the issue
> >> > > > > > > 2.3.1. Any concerns? Discuss on the dev list. Add a
> >> link to
> >> > > > > > > discussion as a comment.
> >> > > > > > > 2.4. All the pacthes (test and fix) should be relative
> >> to the
> >> > > > > > > directory where the main build.xml is:
> >> > > > > > >
> >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/
> >> > > trun
> >> > > > > k
> >> > > > > > > 2.5. If the patch requires to add, remove or move some
> >> files in th
> >> > > e
> >> > > > > > > repository, add the appropriate script.
> >> > > > > > > 2.6. Check that all unit tests pass.
> >> > > > > > > 2.7. If it is an application-oriented issue, check the
> >> application
> >> > > .
> >> > > > > > > 2.8. Remember to use issue links if applicable.
> >> > > > > > >
> >> > > > > > > Committer:
> >> > > > > > > Depending on the issue type, do:
> >> > > > > > > 1. Issue is a non-bug difference, not a bug or invalid:
> >> > > > > > > Close the issue.
> >> > > > > > > 2. Issue is a bug:
> >> > > > > > > 2.1. If a patch to test is available, apply it.
> >> > > > > > > 2.2. Check that the test fails.
> >> > > > > > > 2.3. Apply the fix for the issue.
> >> > > > > > > 2.4. Check that test succeeds now.
> >> > > > > > > 2.5. Make sure that all unit tests pass.
> >> > > > > > > 2.6. For application-oriented issues, check the
> >> application.
> >> > > > > > > 2.7. If there are problems on previous steps, post a
> >> comment to
> >> > > > > > > JIRA and let "resolution provider" to resolve.
> >> > > > > > > 2.8. Make sure that the issue reporter is happy with
> >> the resolutio
> >> > > n.
> >> > > > > > > 2.9. Add revision info into JIRA issue
--
Alexei Zakharov,
Intel Middleware Product 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 21, 2006, at 9:42 AM, Tim Ellison wrote:
> Alexei Zakharov wrote:
>> Hi Alexey,
>>
>> IMHO it would be nice to explicitly state (for issue reports and/or
>> resolution providers) that patch to classlib code and patch to test
>> should be two separate patches. I personally posted several
>> "combined"
>> patches in the past. :)
>
> My preference is for combined patches, if they come from the same
> contributor.
>
> How does it help to attach them separately?
I think it makes it cleaner. You can apply the test patch, w/o the
code mods, and then run and show the tests fail. THen apply the code
patch, show that things get fixed.
geir
>
> Regards,
> Tim
>
>
>> 2006/9/20, Alexey Petrenko <al...@gmail.com>:
>>> 2006/9/20, Mark Hindess <ma...@googlemail.com>:
>>>>
>>>> Alexey,
>>>>
>>>> What was wrong with the initial suggestion of recommending patches
>>>> be either relative to the classlib/trunk or
>>>> classlib/trunk/module/<module-name>?
>>> Seems I was not very attentive...
>>> "Harmony root or module root" looks fine.
>>>
>>> Any other objections or corrections?
>>>
>>> SY, Alexey
>>>
>>>> I really don't care much *except* that there were two specific
>>>> types
>>>> of patches I was trying to avoid as I mentioned when I first
>>>> suggested
>>>> this guideline. So I definitely think a guideline of some form
>>> would be
>>>> constructive.
>>>>
>>>> Regards,
>>>> Mark.
>>>>
>>>> On 20 September 2006 at 15:48, "Alexey Petrenko"
>>> <al...@gmail.com> wrote:
>>>>> Then we should remove this requirement at all...
>>>>> Since it is possible to have a patches for a few modules at
>>>>> once. Or
>>>>> for a few modules and a doc.
>>>>>
>>>>> 2006/9/20, Mark Hindess <ma...@googlemail.com>:
>>>>>>
>>>>>> On 20 September 2006 at 13:56, "Alexey Petrenko"
>>> <alexey.a.petrenko@gmail.c
>>>>> om> wrote:
>>>>>>> Not module build.xml but the main build.xml.
>>>>>>> Anyway since we got a lot of directories except of modules it is
>>>>>>> better to make a diff from the root.
>>>>>>
>>>>>> I anticipate that in time we will have people that only check
>>> out the
>>>>>> module they wish to work on. So I'm happy to see patches
>>> relative to
>>>>>> a module's build.xml directory.
>>>>>>
>>>>>> -Mark.
>>>>>>
>>>>>>
>>>>>>> 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
>>>>>>>> 2.4. All the pacthes (test and fix) should be relative to the
>>>>>>>> directory where the main build.xml is:
>>>>>>>>
>>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
>>> classlib/tr
>>>>> unk
>>>>>>>>
>>>>>>>> As Mark noted, the directory where the module's build.xml is
>>> located
>>>>>>>> is also acceptable.
>>>>>>>>
>>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
>>> classlib/tr
>>>>> unk/
>>>>>>> modules/module_name
>>>>>>>> Generally, making the patch from this directory is much
>>> faster then
>>>>>>>> from the classlib/trunk :)
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/20/06, Alexey Petrenko <al...@gmail.com>
>>> wrote:
>>>>>>>>> I've combined all the ideas. And here is the result.
>>>>>>>>>
>>>>>>>>> === cut ===
>>>>>>>>> Preface
>>>>>>>>> This guideline covers a wide range of issues but not all
>>> of them.
>>>>>>>>> If you cannot do one of the steps, then write a comment to
>>> the issue.
>>>>>>>>> Use your common sense!
>>>>>>>>>
>>>>>>>>> Issue reporter:
>>>>>>>>> 1. Explicitly state the expected behavior and the
>>>>>>>>> actual behavior of Harmony code. Use links to specs, rfcs,
>>> etc.
>>>>>>>>> 2. Try to create as small a test case as possible. A patch
>>>>>>>>> to test will be highly appreciated.
>>>>>>>>> 3. Provide max. information about steps necessary to
>>> recreate the bug
>>>>> .
>>>>>>>>> If a patch for the test has not been supplied, provide as
>>> much
>>>>>>>>> diagnostic information about the failure as possible
>>> (stack trace,
>>>>>>>>> failure output, expected output etc).
>>>>>>>>> 4. Remember to use issue links if applicable.
>>>>>>>>> 5. Check the issue resolution when it is committed. Add a
>>> comment.
>>>>>>>>>
>>>>>>>>> Resolution provider :) :
>>>>>>>>> Depending on the type of issue, do the following:
>>>>>>>>> 1. Issue is probably a non-bug difference, not a bug or
>>> invalid:
>>>>>>>>> 1.1. Discuss on the dev list.
>>>>>>>>> 1.2. Add a link to the discussion thread as a comment
>>> to issue.
>>>>>>>>> 2. Issue is a bug:
>>>>>>>>> 2.1. Notify the community that you started
>>> investigation by adding
>>>>>>>>> a comment to the issue. If you cannot produce a patch, add
>>> another
>>>>>>>>> comment with the results of your investigation.
>>>>>>>>> 2.2. If reporter did not provide a patch to test:
>>>>>>>>> 2.2.1. Try to create a patch to test.
>>>>>>>>> 2.2.2. If you cannot produce a patch, write a
>>> comment about it
>>>>> .
>>>>>>>>> 2.3. Create a patch to fix the issue
>>>>>>>>> 2.3.1. Any concerns? Discuss on the dev list. Add a
>>> link to
>>>>>>>>> discussion as a comment.
>>>>>>>>> 2.4. All the pacthes (test and fix) should be relative
>>> to the
>>>>>>>>> directory where the main build.xml is:
>>>>>>>>>
>>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
>>> classlib/
>>>>> trun
>>>>>>> k
>>>>>>>>> 2.5. If the patch requires to add, remove or move some
>>> files in th
>>>>> e
>>>>>>>>> repository, add the appropriate script.
>>>>>>>>> 2.6. Check that all unit tests pass.
>>>>>>>>> 2.7. If it is an application-oriented issue, check the
>>> application
>>>>> .
>>>>>>>>> 2.8. Remember to use issue links if applicable.
>>>>>>>>>
>>>>>>>>> Committer:
>>>>>>>>> Depending on the issue type, do:
>>>>>>>>> 1. Issue is a non-bug difference, not a bug or invalid:
>>>>>>>>> Close the issue.
>>>>>>>>> 2. Issue is a bug:
>>>>>>>>> 2.1. If a patch to test is available, apply it.
>>>>>>>>> 2.2. Check that the test fails.
>>>>>>>>> 2.3. Apply the fix for the issue.
>>>>>>>>> 2.4. Check that test succeeds now.
>>>>>>>>> 2.5. Make sure that all unit tests pass.
>>>>>>>>> 2.6. For application-oriented issues, check the
>>> application.
>>>>>>>>> 2.7. If there are problems on previous steps, post a
>>> comment to
>>>>>>>>> JIRA and let "resolution provider" to resolve.
>>>>>>>>> 2.8. Make sure that the issue reporter is happy with
>>> the resolutio
>>>>> n.
>>>>>>>>> 2.9. Add revision info into JIRA issue
>>>>>>>>>
>>
>>
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer
to supply patches for old JIRAs)
Posted by Tim Ellison <t....@gmail.com>.
Alexei Zakharov wrote:
> Hi Alexey,
>
> IMHO it would be nice to explicitly state (for issue reports and/or
> resolution providers) that patch to classlib code and patch to test
> should be two separate patches. I personally posted several "combined"
> patches in the past. :)
My preference is for combined patches, if they come from the same
contributor.
How does it help to attach them separately?
Regards,
Tim
> 2006/9/20, Alexey Petrenko <al...@gmail.com>:
>> 2006/9/20, Mark Hindess <ma...@googlemail.com>:
>> >
>> > Alexey,
>> >
>> > What was wrong with the initial suggestion of recommending patches
>> > be either relative to the classlib/trunk or
>> > classlib/trunk/module/<module-name>?
>> Seems I was not very attentive...
>> "Harmony root or module root" looks fine.
>>
>> Any other objections or corrections?
>>
>> SY, Alexey
>>
>> > I really don't care much *except* that there were two specific types
>> > of patches I was trying to avoid as I mentioned when I first suggested
>> > this guideline. So I definitely think a guideline of some form
>> would be
>> > constructive.
>> >
>> > Regards,
>> > Mark.
>> >
>> > On 20 September 2006 at 15:48, "Alexey Petrenko"
>> <al...@gmail.com> wrote:
>> > > Then we should remove this requirement at all...
>> > > Since it is possible to have a patches for a few modules at once. Or
>> > > for a few modules and a doc.
>> > >
>> > > 2006/9/20, Mark Hindess <ma...@googlemail.com>:
>> > > >
>> > > > On 20 September 2006 at 13:56, "Alexey Petrenko"
>> <alexey.a.petrenko@gmail.c
>> > > om> wrote:
>> > > > > Not module build.xml but the main build.xml.
>> > > > > Anyway since we got a lot of directories except of modules it is
>> > > > > better to make a diff from the root.
>> > > >
>> > > > I anticipate that in time we will have people that only check
>> out the
>> > > > module they wish to work on. So I'm happy to see patches
>> relative to
>> > > > a module's build.xml directory.
>> > > >
>> > > > -Mark.
>> > > >
>> > > >
>> > > > > 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
>> > > > > > 2.4. All the pacthes (test and fix) should be relative to the
>> > > > > > directory where the main build.xml is:
>> > > > > >
>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
>> > > unk
>> > > > > >
>> > > > > > As Mark noted, the directory where the module's build.xml is
>> located
>> > > > > > is also acceptable.
>> > > > > >
>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
>> > > unk/
>> > > > > modules/module_name
>> > > > > > Generally, making the patch from this directory is much
>> faster then
>> > > > > > from the classlib/trunk :)
>> > > > > >
>> > > > > >
>> > > > > > On 9/20/06, Alexey Petrenko <al...@gmail.com>
>> wrote:
>> > > > > > > I've combined all the ideas. And here is the result.
>> > > > > > >
>> > > > > > > === cut ===
>> > > > > > > Preface
>> > > > > > > This guideline covers a wide range of issues but not all
>> of them.
>> > > > > > > If you cannot do one of the steps, then write a comment to
>> the issue.
>> > > > > > > Use your common sense!
>> > > > > > >
>> > > > > > > Issue reporter:
>> > > > > > > 1. Explicitly state the expected behavior and the
>> > > > > > > actual behavior of Harmony code. Use links to specs, rfcs,
>> etc.
>> > > > > > > 2. Try to create as small a test case as possible. A patch
>> > > > > > > to test will be highly appreciated.
>> > > > > > > 3. Provide max. information about steps necessary to
>> recreate the bug
>> > > .
>> > > > > > > If a patch for the test has not been supplied, provide as
>> much
>> > > > > > > diagnostic information about the failure as possible
>> (stack trace,
>> > > > > > > failure output, expected output etc).
>> > > > > > > 4. Remember to use issue links if applicable.
>> > > > > > > 5. Check the issue resolution when it is committed. Add a
>> comment.
>> > > > > > >
>> > > > > > > Resolution provider :) :
>> > > > > > > Depending on the type of issue, do the following:
>> > > > > > > 1. Issue is probably a non-bug difference, not a bug or
>> invalid:
>> > > > > > > 1.1. Discuss on the dev list.
>> > > > > > > 1.2. Add a link to the discussion thread as a comment
>> to issue.
>> > > > > > > 2. Issue is a bug:
>> > > > > > > 2.1. Notify the community that you started
>> investigation by adding
>> > > > > > > a comment to the issue. If you cannot produce a patch, add
>> another
>> > > > > > > comment with the results of your investigation.
>> > > > > > > 2.2. If reporter did not provide a patch to test:
>> > > > > > > 2.2.1. Try to create a patch to test.
>> > > > > > > 2.2.2. If you cannot produce a patch, write a
>> comment about it
>> > > .
>> > > > > > > 2.3. Create a patch to fix the issue
>> > > > > > > 2.3.1. Any concerns? Discuss on the dev list. Add a
>> link to
>> > > > > > > discussion as a comment.
>> > > > > > > 2.4. All the pacthes (test and fix) should be relative
>> to the
>> > > > > > > directory where the main build.xml is:
>> > > > > > >
>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/
>> > > trun
>> > > > > k
>> > > > > > > 2.5. If the patch requires to add, remove or move some
>> files in th
>> > > e
>> > > > > > > repository, add the appropriate script.
>> > > > > > > 2.6. Check that all unit tests pass.
>> > > > > > > 2.7. If it is an application-oriented issue, check the
>> application
>> > > .
>> > > > > > > 2.8. Remember to use issue links if applicable.
>> > > > > > >
>> > > > > > > Committer:
>> > > > > > > Depending on the issue type, do:
>> > > > > > > 1. Issue is a non-bug difference, not a bug or invalid:
>> > > > > > > Close the issue.
>> > > > > > > 2. Issue is a bug:
>> > > > > > > 2.1. If a patch to test is available, apply it.
>> > > > > > > 2.2. Check that the test fails.
>> > > > > > > 2.3. Apply the fix for the issue.
>> > > > > > > 2.4. Check that test succeeds now.
>> > > > > > > 2.5. Make sure that all unit tests pass.
>> > > > > > > 2.6. For application-oriented issues, check the
>> application.
>> > > > > > > 2.7. If there are problems on previous steps, post a
>> comment to
>> > > > > > > JIRA and let "resolution provider" to resolve.
>> > > > > > > 2.8. Make sure that the issue reporter is happy with
>> the resolutio
>> > > n.
>> > > > > > > 2.9. Add revision info into JIRA issue
>> > > > > > >
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
Good point! Thanks.
2006/9/21, Alexei Zakharov <al...@gmail.com>:
> Hi Alexey,
>
> IMHO it would be nice to explicitly state (for issue reports and/or
> resolution providers) that patch to classlib code and patch to test
> should be two separate patches. I personally posted several "combined"
> patches in the past. :)
>
> Regards,
>
> 2006/9/20, Alexey Petrenko <al...@gmail.com>:
> > 2006/9/20, Mark Hindess <ma...@googlemail.com>:
> > >
> > > Alexey,
> > >
> > > What was wrong with the initial suggestion of recommending patches
> > > be either relative to the classlib/trunk or
> > > classlib/trunk/module/<module-name>?
> > Seems I was not very attentive...
> > "Harmony root or module root" looks fine.
> >
> > Any other objections or corrections?
> >
> > SY, Alexey
> >
> > > I really don't care much *except* that there were two specific types
> > > of patches I was trying to avoid as I mentioned when I first suggested
> > > this guideline. So I definitely think a guideline of some form would be
> > > constructive.
> > >
> > > Regards,
> > > Mark.
> > >
> > > On 20 September 2006 at 15:48, "Alexey Petrenko" <al...@gmail.com> wrote:
> > > > Then we should remove this requirement at all...
> > > > Since it is possible to have a patches for a few modules at once. Or
> > > > for a few modules and a doc.
> > > >
> > > > 2006/9/20, Mark Hindess <ma...@googlemail.com>:
> > > > >
> > > > > On 20 September 2006 at 13:56, "Alexey Petrenko" <alexey.a.petrenko@gmail.c
> > > > om> wrote:
> > > > > > Not module build.xml but the main build.xml.
> > > > > > Anyway since we got a lot of directories except of modules it is
> > > > > > better to make a diff from the root.
> > > > >
> > > > > I anticipate that in time we will have people that only check out the
> > > > > module they wish to work on. So I'm happy to see patches relative to
> > > > > a module's build.xml directory.
> > > > >
> > > > > -Mark.
> > > > >
> > > > >
> > > > > > 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
> > > > > > > 2.4. All the pacthes (test and fix) should be relative to the
> > > > > > > directory where the main build.xml is:
> > > > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> > > > unk
> > > > > > >
> > > > > > > As Mark noted, the directory where the module's build.xml is located
> > > > > > > is also acceptable.
> > > > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> > > > unk/
> > > > > > modules/module_name
> > > > > > > Generally, making the patch from this directory is much faster then
> > > > > > > from the classlib/trunk :)
> > > > > > >
> > > > > > >
> > > > > > > On 9/20/06, Alexey Petrenko <al...@gmail.com> wrote:
> > > > > > > > I've combined all the ideas. And here is the result.
> > > > > > > >
> > > > > > > > === cut ===
> > > > > > > > Preface
> > > > > > > > This guideline covers a wide range of issues but not all of them.
> > > > > > > > If you cannot do one of the steps, then write a comment to the issue.
> > > > > > > > Use your common sense!
> > > > > > > >
> > > > > > > > Issue reporter:
> > > > > > > > 1. Explicitly state the expected behavior and the
> > > > > > > > actual behavior of Harmony code. Use links to specs, rfcs, etc.
> > > > > > > > 2. Try to create as small a test case as possible. A patch
> > > > > > > > to test will be highly appreciated.
> > > > > > > > 3. Provide max. information about steps necessary to recreate the bug
> > > > .
> > > > > > > > If a patch for the test has not been supplied, provide as much
> > > > > > > > diagnostic information about the failure as possible (stack trace,
> > > > > > > > failure output, expected output etc).
> > > > > > > > 4. Remember to use issue links if applicable.
> > > > > > > > 5. Check the issue resolution when it is committed. Add a comment.
> > > > > > > >
> > > > > > > > Resolution provider :) :
> > > > > > > > Depending on the type of issue, do the following:
> > > > > > > > 1. Issue is probably a non-bug difference, not a bug or invalid:
> > > > > > > > 1.1. Discuss on the dev list.
> > > > > > > > 1.2. Add a link to the discussion thread as a comment to issue.
> > > > > > > > 2. Issue is a bug:
> > > > > > > > 2.1. Notify the community that you started investigation by adding
> > > > > > > > a comment to the issue. If you cannot produce a patch, add another
> > > > > > > > comment with the results of your investigation.
> > > > > > > > 2.2. If reporter did not provide a patch to test:
> > > > > > > > 2.2.1. Try to create a patch to test.
> > > > > > > > 2.2.2. If you cannot produce a patch, write a comment about it
> > > > .
> > > > > > > > 2.3. Create a patch to fix the issue
> > > > > > > > 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> > > > > > > > discussion as a comment.
> > > > > > > > 2.4. All the pacthes (test and fix) should be relative to the
> > > > > > > > directory where the main build.xml is:
> > > > > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/
> > > > trun
> > > > > > k
> > > > > > > > 2.5. If the patch requires to add, remove or move some files in th
> > > > e
> > > > > > > > repository, add the appropriate script.
> > > > > > > > 2.6. Check that all unit tests pass.
> > > > > > > > 2.7. If it is an application-oriented issue, check the application
> > > > .
> > > > > > > > 2.8. Remember to use issue links if applicable.
> > > > > > > >
> > > > > > > > Committer:
> > > > > > > > Depending on the issue type, do:
> > > > > > > > 1. Issue is a non-bug difference, not a bug or invalid:
> > > > > > > > Close the issue.
> > > > > > > > 2. Issue is a bug:
> > > > > > > > 2.1. If a patch to test is available, apply it.
> > > > > > > > 2.2. Check that the test fails.
> > > > > > > > 2.3. Apply the fix for the issue.
> > > > > > > > 2.4. Check that test succeeds now.
> > > > > > > > 2.5. Make sure that all unit tests pass.
> > > > > > > > 2.6. For application-oriented issues, check the application.
> > > > > > > > 2.7. If there are problems on previous steps, post a comment to
> > > > > > > > JIRA and let "resolution provider" to resolve.
> > > > > > > > 2.8. Make sure that the issue reporter is happy with the resolutio
> > > > n.
> > > > > > > > 2.9. Add revision info into JIRA issue
> > > > > > > >
>
>
> --
> Alexei Zakharov,
> Intel Middleware Product 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
>
>
--
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
YES PLEASE :)
On Sep 21, 2006, at 6:37 AM, Alexei Zakharov wrote:
> Hi Alexey,
>
> IMHO it would be nice to explicitly state (for issue reports and/or
> resolution providers) that patch to classlib code and patch to test
> should be two separate patches. I personally posted several "combined"
> patches in the past. :)
>
> Regards,
>
> 2006/9/20, Alexey Petrenko <al...@gmail.com>:
>> 2006/9/20, Mark Hindess <ma...@googlemail.com>:
>> >
>> > Alexey,
>> >
>> > What was wrong with the initial suggestion of recommending patches
>> > be either relative to the classlib/trunk or
>> > classlib/trunk/module/<module-name>?
>> Seems I was not very attentive...
>> "Harmony root or module root" looks fine.
>>
>> Any other objections or corrections?
>>
>> SY, Alexey
>>
>> > I really don't care much *except* that there were two specific
>> types
>> > of patches I was trying to avoid as I mentioned when I first
>> suggested
>> > this guideline. So I definitely think a guideline of some form
>> would be
>> > constructive.
>> >
>> > Regards,
>> > Mark.
>> >
>> > On 20 September 2006 at 15:48, "Alexey Petrenko"
>> <al...@gmail.com> wrote:
>> > > Then we should remove this requirement at all...
>> > > Since it is possible to have a patches for a few modules at
>> once. Or
>> > > for a few modules and a doc.
>> > >
>> > > 2006/9/20, Mark Hindess <ma...@googlemail.com>:
>> > > >
>> > > > On 20 September 2006 at 13:56, "Alexey Petrenko"
>> <alexey.a.petrenko@gmail.c
>> > > om> wrote:
>> > > > > Not module build.xml but the main build.xml.
>> > > > > Anyway since we got a lot of directories except of modules
>> it is
>> > > > > better to make a diff from the root.
>> > > >
>> > > > I anticipate that in time we will have people that only
>> check out the
>> > > > module they wish to work on. So I'm happy to see patches
>> relative to
>> > > > a module's build.xml directory.
>> > > >
>> > > > -Mark.
>> > > >
>> > > >
>> > > > > 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
>> > > > > > 2.4. All the pacthes (test and fix) should be relative
>> to the
>> > > > > > directory where the main build.xml is:
>> > > > > > https://svn.apache.org/repos/asf/incubator/harmony/
>> enhanced/classlib/tr
>> > > unk
>> > > > > >
>> > > > > > As Mark noted, the directory where the module's
>> build.xml is located
>> > > > > > is also acceptable.
>> > > > > > https://svn.apache.org/repos/asf/incubator/harmony/
>> enhanced/classlib/tr
>> > > unk/
>> > > > > modules/module_name
>> > > > > > Generally, making the patch from this directory is much
>> faster then
>> > > > > > from the classlib/trunk :)
>> > > > > >
>> > > > > >
>> > > > > > On 9/20/06, Alexey Petrenko
>> <al...@gmail.com> wrote:
>> > > > > > > I've combined all the ideas. And here is the result.
>> > > > > > >
>> > > > > > > === cut ===
>> > > > > > > Preface
>> > > > > > > This guideline covers a wide range of issues but not
>> all of them.
>> > > > > > > If you cannot do one of the steps, then write a
>> comment to the issue.
>> > > > > > > Use your common sense!
>> > > > > > >
>> > > > > > > Issue reporter:
>> > > > > > > 1. Explicitly state the expected behavior and the
>> > > > > > > actual behavior of Harmony code. Use links to specs,
>> rfcs, etc.
>> > > > > > > 2. Try to create as small a test case as possible. A
>> patch
>> > > > > > > to test will be highly appreciated.
>> > > > > > > 3. Provide max. information about steps necessary to
>> recreate the bug
>> > > .
>> > > > > > > If a patch for the test has not been supplied, provide
>> as much
>> > > > > > > diagnostic information about the failure as possible
>> (stack trace,
>> > > > > > > failure output, expected output etc).
>> > > > > > > 4. Remember to use issue links if applicable.
>> > > > > > > 5. Check the issue resolution when it is committed.
>> Add a comment.
>> > > > > > >
>> > > > > > > Resolution provider :) :
>> > > > > > > Depending on the type of issue, do the following:
>> > > > > > > 1. Issue is probably a non-bug difference, not a bug
>> or invalid:
>> > > > > > > 1.1. Discuss on the dev list.
>> > > > > > > 1.2. Add a link to the discussion thread as a
>> comment to issue.
>> > > > > > > 2. Issue is a bug:
>> > > > > > > 2.1. Notify the community that you started
>> investigation by adding
>> > > > > > > a comment to the issue. If you cannot produce a patch,
>> add another
>> > > > > > > comment with the results of your investigation.
>> > > > > > > 2.2. If reporter did not provide a patch to test:
>> > > > > > > 2.2.1. Try to create a patch to test.
>> > > > > > > 2.2.2. If you cannot produce a patch, write a
>> comment about it
>> > > .
>> > > > > > > 2.3. Create a patch to fix the issue
>> > > > > > > 2.3.1. Any concerns? Discuss on the dev list.
>> Add a link to
>> > > > > > > discussion as a comment.
>> > > > > > > 2.4. All the pacthes (test and fix) should be
>> relative to the
>> > > > > > > directory where the main build.xml is:
>> > > > > > > https://svn.apache.org/repos/asf/incubator/harmony/
>> enhanced/classlib/
>> > > trun
>> > > > > k
>> > > > > > > 2.5. If the patch requires to add, remove or move
>> some files in th
>> > > e
>> > > > > > > repository, add the appropriate script.
>> > > > > > > 2.6. Check that all unit tests pass.
>> > > > > > > 2.7. If it is an application-oriented issue, check
>> the application
>> > > .
>> > > > > > > 2.8. Remember to use issue links if applicable.
>> > > > > > >
>> > > > > > > Committer:
>> > > > > > > Depending on the issue type, do:
>> > > > > > > 1. Issue is a non-bug difference, not a bug or invalid:
>> > > > > > > Close the issue.
>> > > > > > > 2. Issue is a bug:
>> > > > > > > 2.1. If a patch to test is available, apply it.
>> > > > > > > 2.2. Check that the test fails.
>> > > > > > > 2.3. Apply the fix for the issue.
>> > > > > > > 2.4. Check that test succeeds now.
>> > > > > > > 2.5. Make sure that all unit tests pass.
>> > > > > > > 2.6. For application-oriented issues, check the
>> application.
>> > > > > > > 2.7. If there are problems on previous steps, post
>> a comment to
>> > > > > > > JIRA and let "resolution provider" to resolve.
>> > > > > > > 2.8. Make sure that the issue reporter is happy
>> with the resolutio
>> > > n.
>> > > > > > > 2.9. Add revision info into JIRA issue
>> > > > > > >
>
>
> --
> Alexei Zakharov,
> Intel Middleware Product 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexei Zakharov <al...@gmail.com>.
Hi Alexey,
IMHO it would be nice to explicitly state (for issue reports and/or
resolution providers) that patch to classlib code and patch to test
should be two separate patches. I personally posted several "combined"
patches in the past. :)
Regards,
2006/9/20, Alexey Petrenko <al...@gmail.com>:
> 2006/9/20, Mark Hindess <ma...@googlemail.com>:
> >
> > Alexey,
> >
> > What was wrong with the initial suggestion of recommending patches
> > be either relative to the classlib/trunk or
> > classlib/trunk/module/<module-name>?
> Seems I was not very attentive...
> "Harmony root or module root" looks fine.
>
> Any other objections or corrections?
>
> SY, Alexey
>
> > I really don't care much *except* that there were two specific types
> > of patches I was trying to avoid as I mentioned when I first suggested
> > this guideline. So I definitely think a guideline of some form would be
> > constructive.
> >
> > Regards,
> > Mark.
> >
> > On 20 September 2006 at 15:48, "Alexey Petrenko" <al...@gmail.com> wrote:
> > > Then we should remove this requirement at all...
> > > Since it is possible to have a patches for a few modules at once. Or
> > > for a few modules and a doc.
> > >
> > > 2006/9/20, Mark Hindess <ma...@googlemail.com>:
> > > >
> > > > On 20 September 2006 at 13:56, "Alexey Petrenko" <alexey.a.petrenko@gmail.c
> > > om> wrote:
> > > > > Not module build.xml but the main build.xml.
> > > > > Anyway since we got a lot of directories except of modules it is
> > > > > better to make a diff from the root.
> > > >
> > > > I anticipate that in time we will have people that only check out the
> > > > module they wish to work on. So I'm happy to see patches relative to
> > > > a module's build.xml directory.
> > > >
> > > > -Mark.
> > > >
> > > >
> > > > > 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
> > > > > > 2.4. All the pacthes (test and fix) should be relative to the
> > > > > > directory where the main build.xml is:
> > > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> > > unk
> > > > > >
> > > > > > As Mark noted, the directory where the module's build.xml is located
> > > > > > is also acceptable.
> > > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> > > unk/
> > > > > modules/module_name
> > > > > > Generally, making the patch from this directory is much faster then
> > > > > > from the classlib/trunk :)
> > > > > >
> > > > > >
> > > > > > On 9/20/06, Alexey Petrenko <al...@gmail.com> wrote:
> > > > > > > I've combined all the ideas. And here is the result.
> > > > > > >
> > > > > > > === cut ===
> > > > > > > Preface
> > > > > > > This guideline covers a wide range of issues but not all of them.
> > > > > > > If you cannot do one of the steps, then write a comment to the issue.
> > > > > > > Use your common sense!
> > > > > > >
> > > > > > > Issue reporter:
> > > > > > > 1. Explicitly state the expected behavior and the
> > > > > > > actual behavior of Harmony code. Use links to specs, rfcs, etc.
> > > > > > > 2. Try to create as small a test case as possible. A patch
> > > > > > > to test will be highly appreciated.
> > > > > > > 3. Provide max. information about steps necessary to recreate the bug
> > > .
> > > > > > > If a patch for the test has not been supplied, provide as much
> > > > > > > diagnostic information about the failure as possible (stack trace,
> > > > > > > failure output, expected output etc).
> > > > > > > 4. Remember to use issue links if applicable.
> > > > > > > 5. Check the issue resolution when it is committed. Add a comment.
> > > > > > >
> > > > > > > Resolution provider :) :
> > > > > > > Depending on the type of issue, do the following:
> > > > > > > 1. Issue is probably a non-bug difference, not a bug or invalid:
> > > > > > > 1.1. Discuss on the dev list.
> > > > > > > 1.2. Add a link to the discussion thread as a comment to issue.
> > > > > > > 2. Issue is a bug:
> > > > > > > 2.1. Notify the community that you started investigation by adding
> > > > > > > a comment to the issue. If you cannot produce a patch, add another
> > > > > > > comment with the results of your investigation.
> > > > > > > 2.2. If reporter did not provide a patch to test:
> > > > > > > 2.2.1. Try to create a patch to test.
> > > > > > > 2.2.2. If you cannot produce a patch, write a comment about it
> > > .
> > > > > > > 2.3. Create a patch to fix the issue
> > > > > > > 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> > > > > > > discussion as a comment.
> > > > > > > 2.4. All the pacthes (test and fix) should be relative to the
> > > > > > > directory where the main build.xml is:
> > > > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/
> > > trun
> > > > > k
> > > > > > > 2.5. If the patch requires to add, remove or move some files in th
> > > e
> > > > > > > repository, add the appropriate script.
> > > > > > > 2.6. Check that all unit tests pass.
> > > > > > > 2.7. If it is an application-oriented issue, check the application
> > > .
> > > > > > > 2.8. Remember to use issue links if applicable.
> > > > > > >
> > > > > > > Committer:
> > > > > > > Depending on the issue type, do:
> > > > > > > 1. Issue is a non-bug difference, not a bug or invalid:
> > > > > > > Close the issue.
> > > > > > > 2. Issue is a bug:
> > > > > > > 2.1. If a patch to test is available, apply it.
> > > > > > > 2.2. Check that the test fails.
> > > > > > > 2.3. Apply the fix for the issue.
> > > > > > > 2.4. Check that test succeeds now.
> > > > > > > 2.5. Make sure that all unit tests pass.
> > > > > > > 2.6. For application-oriented issues, check the application.
> > > > > > > 2.7. If there are problems on previous steps, post a comment to
> > > > > > > JIRA and let "resolution provider" to resolve.
> > > > > > > 2.8. Make sure that the issue reporter is happy with the resolutio
> > > n.
> > > > > > > 2.9. Add revision info into JIRA issue
> > > > > > >
--
Alexei Zakharov,
Intel Middleware Product 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
2006/9/20, Mark Hindess <ma...@googlemail.com>:
>
> Alexey,
>
> What was wrong with the initial suggestion of recommending patches
> be either relative to the classlib/trunk or
> classlib/trunk/module/<module-name>?
Seems I was not very attentive...
"Harmony root or module root" looks fine.
Any other objections or corrections?
SY, Alexey
> I really don't care much *except* that there were two specific types
> of patches I was trying to avoid as I mentioned when I first suggested
> this guideline. So I definitely think a guideline of some form would be
> constructive.
>
> Regards,
> Mark.
>
> On 20 September 2006 at 15:48, "Alexey Petrenko" <al...@gmail.com> wrote:
> > Then we should remove this requirement at all...
> > Since it is possible to have a patches for a few modules at once. Or
> > for a few modules and a doc.
> >
> > 2006/9/20, Mark Hindess <ma...@googlemail.com>:
> > >
> > > On 20 September 2006 at 13:56, "Alexey Petrenko" <alexey.a.petrenko@gmail.c
> > om> wrote:
> > > > Not module build.xml but the main build.xml.
> > > > Anyway since we got a lot of directories except of modules it is
> > > > better to make a diff from the root.
> > >
> > > I anticipate that in time we will have people that only check out the
> > > module they wish to work on. So I'm happy to see patches relative to
> > > a module's build.xml directory.
> > >
> > > -Mark.
> > >
> > >
> > > > 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
> > > > > 2.4. All the pacthes (test and fix) should be relative to the
> > > > > directory where the main build.xml is:
> > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> > unk
> > > > >
> > > > > As Mark noted, the directory where the module's build.xml is located
> > > > > is also acceptable.
> > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> > unk/
> > > > modules/module_name
> > > > > Generally, making the patch from this directory is much faster then
> > > > > from the classlib/trunk :)
> > > > >
> > > > >
> > > > > On 9/20/06, Alexey Petrenko <al...@gmail.com> wrote:
> > > > > > I've combined all the ideas. And here is the result.
> > > > > >
> > > > > > === cut ===
> > > > > > Preface
> > > > > > This guideline covers a wide range of issues but not all of them.
> > > > > > If you cannot do one of the steps, then write a comment to the issue.
> > > > > > Use your common sense!
> > > > > >
> > > > > > Issue reporter:
> > > > > > 1. Explicitly state the expected behavior and the
> > > > > > actual behavior of Harmony code. Use links to specs, rfcs, etc.
> > > > > > 2. Try to create as small a test case as possible. A patch
> > > > > > to test will be highly appreciated.
> > > > > > 3. Provide max. information about steps necessary to recreate the bug
> > .
> > > > > > If a patch for the test has not been supplied, provide as much
> > > > > > diagnostic information about the failure as possible (stack trace,
> > > > > > failure output, expected output etc).
> > > > > > 4. Remember to use issue links if applicable.
> > > > > > 5. Check the issue resolution when it is committed. Add a comment.
> > > > > >
> > > > > > Resolution provider :) :
> > > > > > Depending on the type of issue, do the following:
> > > > > > 1. Issue is probably a non-bug difference, not a bug or invalid:
> > > > > > 1.1. Discuss on the dev list.
> > > > > > 1.2. Add a link to the discussion thread as a comment to issue.
> > > > > > 2. Issue is a bug:
> > > > > > 2.1. Notify the community that you started investigation by adding
> > > > > > a comment to the issue. If you cannot produce a patch, add another
> > > > > > comment with the results of your investigation.
> > > > > > 2.2. If reporter did not provide a patch to test:
> > > > > > 2.2.1. Try to create a patch to test.
> > > > > > 2.2.2. If you cannot produce a patch, write a comment about it
> > .
> > > > > > 2.3. Create a patch to fix the issue
> > > > > > 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> > > > > > discussion as a comment.
> > > > > > 2.4. All the pacthes (test and fix) should be relative to the
> > > > > > directory where the main build.xml is:
> > > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/
> > trun
> > > > k
> > > > > > 2.5. If the patch requires to add, remove or move some files in th
> > e
> > > > > > repository, add the appropriate script.
> > > > > > 2.6. Check that all unit tests pass.
> > > > > > 2.7. If it is an application-oriented issue, check the application
> > .
> > > > > > 2.8. Remember to use issue links if applicable.
> > > > > >
> > > > > > Committer:
> > > > > > Depending on the issue type, do:
> > > > > > 1. Issue is a non-bug difference, not a bug or invalid:
> > > > > > Close the issue.
> > > > > > 2. Issue is a bug:
> > > > > > 2.1. If a patch to test is available, apply it.
> > > > > > 2.2. Check that the test fails.
> > > > > > 2.3. Apply the fix for the issue.
> > > > > > 2.4. Check that test succeeds now.
> > > > > > 2.5. Make sure that all unit tests pass.
> > > > > > 2.6. For application-oriented issues, check the application.
> > > > > > 2.7. If there are problems on previous steps, post a comment to
> > > > > > JIRA and let "resolution provider" to resolve.
> > > > > > 2.8. Make sure that the issue reporter is happy with the resolutio
> > n.
> > > > > > 2.9. Add revision info into JIRA issue
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > 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.or
> > g
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > 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
> > >
> > >
> >
> >
> > --
> > 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
>
>
--
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Mark Hindess <ma...@googlemail.com>.
Alexey,
What was wrong with the initial suggestion of recommending patches
be either relative to the classlib/trunk or
classlib/trunk/module/<module-name>?
I really don't care much *except* that there were two specific types
of patches I was trying to avoid as I mentioned when I first suggested
this guideline. So I definitely think a guideline of some form would be
constructive.
Regards,
Mark.
On 20 September 2006 at 15:48, "Alexey Petrenko" <al...@gmail.com> wrote:
> Then we should remove this requirement at all...
> Since it is possible to have a patches for a few modules at once. Or
> for a few modules and a doc.
>
> 2006/9/20, Mark Hindess <ma...@googlemail.com>:
> >
> > On 20 September 2006 at 13:56, "Alexey Petrenko" <alexey.a.petrenko@gmail.c
> om> wrote:
> > > Not module build.xml but the main build.xml.
> > > Anyway since we got a lot of directories except of modules it is
> > > better to make a diff from the root.
> >
> > I anticipate that in time we will have people that only check out the
> > module they wish to work on. So I'm happy to see patches relative to
> > a module's build.xml directory.
> >
> > -Mark.
> >
> >
> > > 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
> > > > 2.4. All the pacthes (test and fix) should be relative to the
> > > > directory where the main build.xml is:
> > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> unk
> > > >
> > > > As Mark noted, the directory where the module's build.xml is located
> > > > is also acceptable.
> > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr
> unk/
> > > modules/module_name
> > > > Generally, making the patch from this directory is much faster then
> > > > from the classlib/trunk :)
> > > >
> > > >
> > > > On 9/20/06, Alexey Petrenko <al...@gmail.com> wrote:
> > > > > I've combined all the ideas. And here is the result.
> > > > >
> > > > > === cut ===
> > > > > Preface
> > > > > This guideline covers a wide range of issues but not all of them.
> > > > > If you cannot do one of the steps, then write a comment to the issue.
> > > > > Use your common sense!
> > > > >
> > > > > Issue reporter:
> > > > > 1. Explicitly state the expected behavior and the
> > > > > actual behavior of Harmony code. Use links to specs, rfcs, etc.
> > > > > 2. Try to create as small a test case as possible. A patch
> > > > > to test will be highly appreciated.
> > > > > 3. Provide max. information about steps necessary to recreate the bug
> .
> > > > > If a patch for the test has not been supplied, provide as much
> > > > > diagnostic information about the failure as possible (stack trace,
> > > > > failure output, expected output etc).
> > > > > 4. Remember to use issue links if applicable.
> > > > > 5. Check the issue resolution when it is committed. Add a comment.
> > > > >
> > > > > Resolution provider :) :
> > > > > Depending on the type of issue, do the following:
> > > > > 1. Issue is probably a non-bug difference, not a bug or invalid:
> > > > > 1.1. Discuss on the dev list.
> > > > > 1.2. Add a link to the discussion thread as a comment to issue.
> > > > > 2. Issue is a bug:
> > > > > 2.1. Notify the community that you started investigation by adding
> > > > > a comment to the issue. If you cannot produce a patch, add another
> > > > > comment with the results of your investigation.
> > > > > 2.2. If reporter did not provide a patch to test:
> > > > > 2.2.1. Try to create a patch to test.
> > > > > 2.2.2. If you cannot produce a patch, write a comment about it
> .
> > > > > 2.3. Create a patch to fix the issue
> > > > > 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> > > > > discussion as a comment.
> > > > > 2.4. All the pacthes (test and fix) should be relative to the
> > > > > directory where the main build.xml is:
> > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/
> trun
> > > k
> > > > > 2.5. If the patch requires to add, remove or move some files in th
> e
> > > > > repository, add the appropriate script.
> > > > > 2.6. Check that all unit tests pass.
> > > > > 2.7. If it is an application-oriented issue, check the application
> .
> > > > > 2.8. Remember to use issue links if applicable.
> > > > >
> > > > > Committer:
> > > > > Depending on the issue type, do:
> > > > > 1. Issue is a non-bug difference, not a bug or invalid:
> > > > > Close the issue.
> > > > > 2. Issue is a bug:
> > > > > 2.1. If a patch to test is available, apply it.
> > > > > 2.2. Check that the test fails.
> > > > > 2.3. Apply the fix for the issue.
> > > > > 2.4. Check that test succeeds now.
> > > > > 2.5. Make sure that all unit tests pass.
> > > > > 2.6. For application-oriented issues, check the application.
> > > > > 2.7. If there are problems on previous steps, post a comment to
> > > > > JIRA and let "resolution provider" to resolve.
> > > > > 2.8. Make sure that the issue reporter is happy with the resolutio
> n.
> > > > > 2.9. Add revision info into JIRA issue
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > 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.or
> g
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> >
> >
>
>
> --
> 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
Then we should remove this requirement at all...
Since it is possible to have a patches for a few modules at once. Or
for a few modules and a doc.
2006/9/20, Mark Hindess <ma...@googlemail.com>:
>
> On 20 September 2006 at 13:56, "Alexey Petrenko" <al...@gmail.com> wrote:
> > Not module build.xml but the main build.xml.
> > Anyway since we got a lot of directories except of modules it is
> > better to make a diff from the root.
>
> I anticipate that in time we will have people that only check out the
> module they wish to work on. So I'm happy to see patches relative to
> a module's build.xml directory.
>
> -Mark.
>
>
> > 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
> > > 2.4. All the pacthes (test and fix) should be relative to the
> > > directory where the main build.xml is:
> > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk
> > >
> > > As Mark noted, the directory where the module's build.xml is located
> > > is also acceptable.
> > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/
> > modules/module_name
> > > Generally, making the patch from this directory is much faster then
> > > from the classlib/trunk :)
> > >
> > >
> > > On 9/20/06, Alexey Petrenko <al...@gmail.com> wrote:
> > > > I've combined all the ideas. And here is the result.
> > > >
> > > > === cut ===
> > > > Preface
> > > > This guideline covers a wide range of issues but not all of them.
> > > > If you cannot do one of the steps, then write a comment to the issue.
> > > > Use your common sense!
> > > >
> > > > Issue reporter:
> > > > 1. Explicitly state the expected behavior and the
> > > > actual behavior of Harmony code. Use links to specs, rfcs, etc.
> > > > 2. Try to create as small a test case as possible. A patch
> > > > to test will be highly appreciated.
> > > > 3. Provide max. information about steps necessary to recreate the bug.
> > > > If a patch for the test has not been supplied, provide as much
> > > > diagnostic information about the failure as possible (stack trace,
> > > > failure output, expected output etc).
> > > > 4. Remember to use issue links if applicable.
> > > > 5. Check the issue resolution when it is committed. Add a comment.
> > > >
> > > > Resolution provider :) :
> > > > Depending on the type of issue, do the following:
> > > > 1. Issue is probably a non-bug difference, not a bug or invalid:
> > > > 1.1. Discuss on the dev list.
> > > > 1.2. Add a link to the discussion thread as a comment to issue.
> > > > 2. Issue is a bug:
> > > > 2.1. Notify the community that you started investigation by adding
> > > > a comment to the issue. If you cannot produce a patch, add another
> > > > comment with the results of your investigation.
> > > > 2.2. If reporter did not provide a patch to test:
> > > > 2.2.1. Try to create a patch to test.
> > > > 2.2.2. If you cannot produce a patch, write a comment about it.
> > > > 2.3. Create a patch to fix the issue
> > > > 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> > > > discussion as a comment.
> > > > 2.4. All the pacthes (test and fix) should be relative to the
> > > > directory where the main build.xml is:
> > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trun
> > k
> > > > 2.5. If the patch requires to add, remove or move some files in the
> > > > repository, add the appropriate script.
> > > > 2.6. Check that all unit tests pass.
> > > > 2.7. If it is an application-oriented issue, check the application.
> > > > 2.8. Remember to use issue links if applicable.
> > > >
> > > > Committer:
> > > > Depending on the issue type, do:
> > > > 1. Issue is a non-bug difference, not a bug or invalid:
> > > > Close the issue.
> > > > 2. Issue is a bug:
> > > > 2.1. If a patch to test is available, apply it.
> > > > 2.2. Check that the test fails.
> > > > 2.3. Apply the fix for the issue.
> > > > 2.4. Check that test succeeds now.
> > > > 2.5. Make sure that all unit tests pass.
> > > > 2.6. For application-oriented issues, check the application.
> > > > 2.7. If there are problems on previous steps, post a comment to
> > > > JIRA and let "resolution provider" to resolve.
> > > > 2.8. Make sure that the issue reporter is happy with the resolution.
> > > > 2.9. Add revision info into JIRA issue
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
>
>
--
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Mark Hindess <ma...@googlemail.com>.
On 20 September 2006 at 13:56, "Alexey Petrenko" <al...@gmail.com> wrote:
> Not module build.xml but the main build.xml.
> Anyway since we got a lot of directories except of modules it is
> better to make a diff from the root.
I anticipate that in time we will have people that only check out the
module they wish to work on. So I'm happy to see patches relative to
a module's build.xml directory.
-Mark.
> 2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
> > 2.4. All the pacthes (test and fix) should be relative to the
> > directory where the main build.xml is:
> > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk
> >
> > As Mark noted, the directory where the module's build.xml is located
> > is also acceptable.
> > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/
> modules/module_name
> > Generally, making the patch from this directory is much faster then
> > from the classlib/trunk :)
> >
> >
> > On 9/20/06, Alexey Petrenko <al...@gmail.com> wrote:
> > > I've combined all the ideas. And here is the result.
> > >
> > > === cut ===
> > > Preface
> > > This guideline covers a wide range of issues but not all of them.
> > > If you cannot do one of the steps, then write a comment to the issue.
> > > Use your common sense!
> > >
> > > Issue reporter:
> > > 1. Explicitly state the expected behavior and the
> > > actual behavior of Harmony code. Use links to specs, rfcs, etc.
> > > 2. Try to create as small a test case as possible. A patch
> > > to test will be highly appreciated.
> > > 3. Provide max. information about steps necessary to recreate the bug.
> > > If a patch for the test has not been supplied, provide as much
> > > diagnostic information about the failure as possible (stack trace,
> > > failure output, expected output etc).
> > > 4. Remember to use issue links if applicable.
> > > 5. Check the issue resolution when it is committed. Add a comment.
> > >
> > > Resolution provider :) :
> > > Depending on the type of issue, do the following:
> > > 1. Issue is probably a non-bug difference, not a bug or invalid:
> > > 1.1. Discuss on the dev list.
> > > 1.2. Add a link to the discussion thread as a comment to issue.
> > > 2. Issue is a bug:
> > > 2.1. Notify the community that you started investigation by adding
> > > a comment to the issue. If you cannot produce a patch, add another
> > > comment with the results of your investigation.
> > > 2.2. If reporter did not provide a patch to test:
> > > 2.2.1. Try to create a patch to test.
> > > 2.2.2. If you cannot produce a patch, write a comment about it.
> > > 2.3. Create a patch to fix the issue
> > > 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> > > discussion as a comment.
> > > 2.4. All the pacthes (test and fix) should be relative to the
> > > directory where the main build.xml is:
> > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trun
> k
> > > 2.5. If the patch requires to add, remove or move some files in the
> > > repository, add the appropriate script.
> > > 2.6. Check that all unit tests pass.
> > > 2.7. If it is an application-oriented issue, check the application.
> > > 2.8. Remember to use issue links if applicable.
> > >
> > > Committer:
> > > Depending on the issue type, do:
> > > 1. Issue is a non-bug difference, not a bug or invalid:
> > > Close the issue.
> > > 2. Issue is a bug:
> > > 2.1. If a patch to test is available, apply it.
> > > 2.2. Check that the test fails.
> > > 2.3. Apply the fix for the issue.
> > > 2.4. Check that test succeeds now.
> > > 2.5. Make sure that all unit tests pass.
> > > 2.6. For application-oriented issues, check the application.
> > > 2.7. If there are problems on previous steps, post a comment to
> > > JIRA and let "resolution provider" to resolve.
> > > 2.8. Make sure that the issue reporter is happy with the resolution.
> > > 2.9. Add revision info into JIRA issue
> > >
> > > ---------------------------------------------------------------------
> > > 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
Not module build.xml but the main build.xml.
Anyway since we got a lot of directories except of modules it is
better to make a diff from the root.
2006/9/20, Oleg Khaschansky <ol...@gmail.com>:
> 2.4. All the pacthes (test and fix) should be relative to the
> directory where the main build.xml is:
> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk
>
> As Mark noted, the directory where the module's build.xml is located
> is also acceptable.
> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/modules/module_name
> Generally, making the patch from this directory is much faster then
> from the classlib/trunk :)
>
>
> On 9/20/06, Alexey Petrenko <al...@gmail.com> wrote:
> > I've combined all the ideas. And here is the result.
> >
> > === cut ===
> > Preface
> > This guideline covers a wide range of issues but not all of them.
> > If you cannot do one of the steps, then write a comment to the issue.
> > Use your common sense!
> >
> > Issue reporter:
> > 1. Explicitly state the expected behavior and the
> > actual behavior of Harmony code. Use links to specs, rfcs, etc.
> > 2. Try to create as small a test case as possible. A patch
> > to test will be highly appreciated.
> > 3. Provide max. information about steps necessary to recreate the bug.
> > If a patch for the test has not been supplied, provide as much
> > diagnostic information about the failure as possible (stack trace,
> > failure output, expected output etc).
> > 4. Remember to use issue links if applicable.
> > 5. Check the issue resolution when it is committed. Add a comment.
> >
> > Resolution provider :) :
> > Depending on the type of issue, do the following:
> > 1. Issue is probably a non-bug difference, not a bug or invalid:
> > 1.1. Discuss on the dev list.
> > 1.2. Add a link to the discussion thread as a comment to issue.
> > 2. Issue is a bug:
> > 2.1. Notify the community that you started investigation by adding
> > a comment to the issue. If you cannot produce a patch, add another
> > comment with the results of your investigation.
> > 2.2. If reporter did not provide a patch to test:
> > 2.2.1. Try to create a patch to test.
> > 2.2.2. If you cannot produce a patch, write a comment about it.
> > 2.3. Create a patch to fix the issue
> > 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> > discussion as a comment.
> > 2.4. All the pacthes (test and fix) should be relative to the
> > directory where the main build.xml is:
> > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk
> > 2.5. If the patch requires to add, remove or move some files in the
> > repository, add the appropriate script.
> > 2.6. Check that all unit tests pass.
> > 2.7. If it is an application-oriented issue, check the application.
> > 2.8. Remember to use issue links if applicable.
> >
> > Committer:
> > Depending on the issue type, do:
> > 1. Issue is a non-bug difference, not a bug or invalid:
> > Close the issue.
> > 2. Issue is a bug:
> > 2.1. If a patch to test is available, apply it.
> > 2.2. Check that the test fails.
> > 2.3. Apply the fix for the issue.
> > 2.4. Check that test succeeds now.
> > 2.5. Make sure that all unit tests pass.
> > 2.6. For application-oriented issues, check the application.
> > 2.7. If there are problems on previous steps, post a comment to
> > JIRA and let "resolution provider" to resolve.
> > 2.8. Make sure that the issue reporter is happy with the resolution.
> > 2.9. Add revision info into JIRA issue
> >
> > ---------------------------------------------------------------------
> > 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Oleg Khaschansky <ol...@gmail.com>.
2.4. All the pacthes (test and fix) should be relative to the
directory where the main build.xml is:
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk
As Mark noted, the directory where the module's build.xml is located
is also acceptable.
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/modules/module_name
Generally, making the patch from this directory is much faster then
from the classlib/trunk :)
On 9/20/06, Alexey Petrenko <al...@gmail.com> wrote:
> I've combined all the ideas. And here is the result.
>
> === cut ===
> Preface
> This guideline covers a wide range of issues but not all of them.
> If you cannot do one of the steps, then write a comment to the issue.
> Use your common sense!
>
> Issue reporter:
> 1. Explicitly state the expected behavior and the
> actual behavior of Harmony code. Use links to specs, rfcs, etc.
> 2. Try to create as small a test case as possible. A patch
> to test will be highly appreciated.
> 3. Provide max. information about steps necessary to recreate the bug.
> If a patch for the test has not been supplied, provide as much
> diagnostic information about the failure as possible (stack trace,
> failure output, expected output etc).
> 4. Remember to use issue links if applicable.
> 5. Check the issue resolution when it is committed. Add a comment.
>
> Resolution provider :) :
> Depending on the type of issue, do the following:
> 1. Issue is probably a non-bug difference, not a bug or invalid:
> 1.1. Discuss on the dev list.
> 1.2. Add a link to the discussion thread as a comment to issue.
> 2. Issue is a bug:
> 2.1. Notify the community that you started investigation by adding
> a comment to the issue. If you cannot produce a patch, add another
> comment with the results of your investigation.
> 2.2. If reporter did not provide a patch to test:
> 2.2.1. Try to create a patch to test.
> 2.2.2. If you cannot produce a patch, write a comment about it.
> 2.3. Create a patch to fix the issue
> 2.3.1. Any concerns? Discuss on the dev list. Add a link to
> discussion as a comment.
> 2.4. All the pacthes (test and fix) should be relative to the
> directory where the main build.xml is:
> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk
> 2.5. If the patch requires to add, remove or move some files in the
> repository, add the appropriate script.
> 2.6. Check that all unit tests pass.
> 2.7. If it is an application-oriented issue, check the application.
> 2.8. Remember to use issue links if applicable.
>
> Committer:
> Depending on the issue type, do:
> 1. Issue is a non-bug difference, not a bug or invalid:
> Close the issue.
> 2. Issue is a bug:
> 2.1. If a patch to test is available, apply it.
> 2.2. Check that the test fails.
> 2.3. Apply the fix for the issue.
> 2.4. Check that test succeeds now.
> 2.5. Make sure that all unit tests pass.
> 2.6. For application-oriented issues, check the application.
> 2.7. If there are problems on previous steps, post a comment to
> JIRA and let "resolution provider" to resolve.
> 2.8. Make sure that the issue reporter is happy with the resolution.
> 2.9. Add revision info into JIRA issue
>
> ---------------------------------------------------------------------
> 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
I've combined all the ideas. And here is the result.
=== cut ===
Preface
This guideline covers a wide range of issues but not all of them.
If you cannot do one of the steps, then write a comment to the issue.
Use your common sense!
Issue reporter:
1. Explicitly state the expected behavior and the
actual behavior of Harmony code. Use links to specs, rfcs, etc.
2. Try to create as small a test case as possible. A patch
to test will be highly appreciated.
3. Provide max. information about steps necessary to recreate the bug.
If a patch for the test has not been supplied, provide as much
diagnostic information about the failure as possible (stack trace,
failure output, expected output etc).
4. Remember to use issue links if applicable.
5. Check the issue resolution when it is committed. Add a comment.
Resolution provider :) :
Depending on the type of issue, do the following:
1. Issue is probably a non-bug difference, not a bug or invalid:
1.1. Discuss on the dev list.
1.2. Add a link to the discussion thread as a comment to issue.
2. Issue is a bug:
2.1. Notify the community that you started investigation by adding
a comment to the issue. If you cannot produce a patch, add another
comment with the results of your investigation.
2.2. If reporter did not provide a patch to test:
2.2.1. Try to create a patch to test.
2.2.2. If you cannot produce a patch, write a comment about it.
2.3. Create a patch to fix the issue
2.3.1. Any concerns? Discuss on the dev list. Add a link to
discussion as a comment.
2.4. All the pacthes (test and fix) should be relative to the
directory where the main build.xml is:
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk
2.5. If the patch requires to add, remove or move some files in the
repository, add the appropriate script.
2.6. Check that all unit tests pass.
2.7. If it is an application-oriented issue, check the application.
2.8. Remember to use issue links if applicable.
Committer:
Depending on the issue type, do:
1. Issue is a non-bug difference, not a bug or invalid:
Close the issue.
2. Issue is a bug:
2.1. If a patch to test is available, apply it.
2.2. Check that the test fails.
2.3. Apply the fix for the issue.
2.4. Check that test succeeds now.
2.5. Make sure that all unit tests pass.
2.6. For application-oriented issues, check the application.
2.7. If there are problems on previous steps, post a comment to
JIRA and let "resolution provider" to resolve.
2.8. Make sure that the issue reporter is happy with the resolution.
2.9. Add revision info into JIRA issue
---------------------------------------------------------------------
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer
to supply patches for old JIRAs)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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 <ma...@googlemail.com> wrote:
>>
>>
>> On 15 September 2006 at 12:18, "Vladimir Gorr" <vv...@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 <ma...@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 <ma...@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 <pa...@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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Vladimir Gorr <vv...@gmail.com>.
On 9/15/06, Mark Hindess <ma...@googlemail.com> wrote:
>
>
> On 15 September 2006 at 12:18, "Vladimir Gorr" <vv...@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 <ma...@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 <ma...@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 <pa...@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
>
>
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Mark Hindess <ma...@googlemail.com>.
On 15 September 2006 at 12:18, "Vladimir Gorr" <vv...@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 <ma...@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 <ma...@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 <ma...@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 <pa...@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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Vladimir Gorr <vv...@gmail.com>.
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 <ma...@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 <ma...@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 <ma...@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 <pa...@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
>
>
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Mark Hindess <ma...@googlemail.com>.
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 <ma...@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 <ma...@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 <pa...@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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Mark Hindess <ma...@googlemail.com>.
On 14 September 2006 at 17:13, "Alexey Petrenko" <al...@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 <ma...@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 <ol...@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 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.mbo
> 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: 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 <pa...@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 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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
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 <ma...@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 <ol...@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 <pa...@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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Mark Hindess <ma...@googlemail.com>.
On 15 September 2006 at 8:08, "Alexey Petrenko"
<al...@gmail.com> wrote:
> 2006/9/15, Gregory Shimansky <gs...@gmail.com>:
> > On Thursday 14 September 2006 16:55 Mark Hindess wrote:
> > > 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
> >
> > This probably requires updating the page about downloading the
> > source code on Harmony incubator site. The URL there points to the
> > whole Harmony including standard/ and enhanced/ directories. I think
> > there should be more detailed description about subdirectories in
> > svn repository.
>
> I do not see any problem here. It is possible to checkout all the
> apache svn repository from the root but make diff from classlib/trunk
> :)
Sure you can, but I think this is something we should discourage. If
there is documentation that is encouraging this, as Gregory mentions,
then it should be updated.
Patches for the website would be welcome.
Regards,
Mark.
---------------------------------------------------------------------
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Alexey Petrenko <al...@gmail.com>.
2006/9/15, Gregory Shimansky <gs...@gmail.com>:
> On Thursday 14 September 2006 16:55 Mark Hindess wrote:
> > 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
>
> This probably requires updating the page about downloading the source code on
> Harmony incubator site. The URL there points to the whole Harmony including
> standard/ and enhanced/ directories. I think there should be more detailed
> description about subdirectories in svn repository.
I do not see any problem here.
It is possible to checkout all the apache svn repository from the root
but make diff from classlib/trunk :)
--
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
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Posted by Gregory Shimansky <gs...@gmail.com>.
On Thursday 14 September 2006 16:55 Mark Hindess wrote:
> 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
This probably requires updating the page about downloading the source code on
Harmony incubator site. The URL there points to the whole Harmony including
standard/ and enhanced/ directories. I think there should be more detailed
description about subdirectories in svn repository.
--
Gregory Shimansky, 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