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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
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
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
