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. 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]
