2006/9/20, Mark Hindess <[EMAIL PROTECTED]>:
>
> 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"
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> > >
> > > On 20 September 2006 at 13:56, "Alexey Petrenko"
<[EMAIL PROTECTED]
> > 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 <[EMAIL PROTECTED]>:
> > > > > 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
<[EMAIL PROTECTED]> 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
> > > > > >
