harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Date Mon, 06 Nov 2006 20:59:15 GMT
2006/11/6, Alexei Fedotov <alexei.fedotov@gmail.com>:
> All,
>
> I have added a patch to
> http://issues.apache.org/jira/browse/HARMONY-2077 [doc] Good issue
> resolution guideline,
> though some things are rephrased though.
I do not think that we need to insert this guideline to "get involved"
page. I personally prefer separate document.

And text in your patch looks totally different to the text which was
agreed on harmony-dev list.

SY, Alexey

> On 11/6/06, Fedotov, Alexei A <alexei.a.fedotov@intel.com> wrote:
> > 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
> > >>
> >
>
>
> --
> Thank you,
> Alexei
>

Mime
View raw message