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]
