harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fedotov, Alexei A" <alexei.a.fedo...@intel.com>
Subject RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Date Mon, 06 Nov 2006 12:43:01 GMT
Alexey,

Thank you for your answer. Yesterday I tried to prepare an appropriate
patch for get-involved.html but faced several things I couldn't resolve
myself. I didn't criticize your text - I was thinking how to fit it into
get-involved.html. That is why I raised all these questions.

I still have one question which is important, to my mind. You wrote,
>DRLVM is not the only Harmony VM. I think that developer can choose
>which VM to use.

1.  As Geir says, we are small community, and we need to keep ourselves
concentrated. Can we give a recommendation to concentrate on one
specific VM assuming that VM which is shipped with Harmony 1.0?

2. What is the status of DRLVM smoke tests? As any tests written in java
they have a dependency from a class library. Do you think they should be
skipped while testing the patch?

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

>-----Original Message-----
>From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
>Sent: Monday, November 06, 2006 2:03 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [jira] Good issue resolution guideline (was:
>[classlib]volunteer to supply patches for old JIRAs)
>
>2006/11/6, Fedotov, Alexei A <alexei.a.fedotov@intel.com>:
>> Alexey,
>>
>> I started looking into this thread. Are guidelines on the web site
>> already? I failed to find them.
>No, this guideline is not published yet.
>I'll do this in the nearest future.
>
>> I thought about adding them to get-involved.html. Here are few
problems
>> I've noticed:
>First of all....
>As you know patches are always welcome in Harmony :)
>
>> 1. The detail level of your instruction is somewhat different from
>> get-involved.html. This text is formal, while the text on the page is
>> quite informal.
>I do not see problem here.
>
>> 2. If a guy has a test in a separate file, should he produce a patch
>> from such file and submit the patch? According to guidelines, the
answer
>> is yes.
>Do you mean "in a new file"? Yes, a new file should be provided as a
>patch too. Why not?
>
>> According to my common sense patches are good when you modify
>> existing files.
>Yes, they are good for modified files. And they also can be used for
>adding and removing files.
>
>> 3. Why it is not suggested for an issue reporter to try localizing a
>> buggy module
>I think that points 2 and 3 are saying this.
>
>> or even fixing the problem?
>Nobody said that an "issue reporter" can not be a "resolution
provider".
>
>
>> 4. Item 4. of issue reporter guidelines doesn't contain enough
details
>> for my taste. I believe links should be descriptive:
>>   Link the issue to previous posts, JIRAs, RI bugs, etc.
>Probably your sentence is better. Need to think.
>
>> 5. The item 2.1 of resolution provider guidelines contains too many
>> details to my mind. Here should be something like a following text
(for
>> all roles):
>>   a. Update JIRA once per day reporting your progress.
>>   b. Always keep the community posted.
>What for? Why do you want to have DAILY posts on ALL the working
issues?
>I think that we do not need to change anything here since comunity has
>agreed on the list of notifications it wants to see. And all these
>cases are described there.
>
>> 6. The item 2.4 refers to class library build.xml as a main
build.xml.
>Patches are welcome :)
>
>> 7. You do not specify which unit tests should pass and which VM
should
>> be used. Since the changes could affect DRLVM, I would say that all
unit
>> tests should pass for DRLVM unless the fall into exclude list.
>DRLVM is not the only Harmony VM. I think that developer can choose
>which VM to use.
>
>> 8. I believe a verification stage should happen before committer
commits
>> a patch - this would save his time if the issue doesn't resolve the
>> problem.
>Yes, and nobody argue with this.
>
>SY, Alexey
>
>> >-----Original Message-----
>> >From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
>> >Sent: Thursday, September 28, 2006 5:02 PM
>> >To: harmony-dev@incubator.apache.org
>> >Subject: Re: [jira] Good issue resolution guideline (was:
>> >[classlib]volunteer to supply patches for old JIRAs)
>> >
>> >:)
>> >
>> >Yes, I'll prepare a patch.
>> >
>> >2006/9/28, Geir Magnusson Jr. <geir@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 <alexey.a.petrenko@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
>>

Mime
View raw message