I'm just trying to figure out if r713673 is the final version from chunrong -- then we can all be testing it again.
Regards, Tim Pavel Pervov wrote: > +1 for (2) > > WBR, > Pavel. > > On Thu, Nov 13, 2008 at 10:09 AM, Sean Qiu <[EMAIL PROTECTED]> wrote: >> option 2 sounds reasonable for me, anyway quality overweigh others. >> >> +1 for (2) in addition to Sian's comment. >> >> 2008/11/12 Sian January <[EMAIL PROTECTED]> >> >>> Presumably with option (2) we would still run the Harmony Classlib and >>> DRLVM test suites as part of the build? If so, then (2) would be my >>> preference. >>> >>> >>> >>> 2008/11/12 Aleksey Shipilev <[EMAIL PROTECTED]>: >>>> Tim, I see the good point in your explanation too. >>>> >>>> So we need to consider three options: >>>> Option 1. Go with r711744 as M8. It is already tested, so just solidify >>> build. >>>> Option 2. Fix H6013, declare r711744 + H6013 as M8, presume the >>>> impact locality, solidify the build. >>>> Option 3. Fix H6013, declare r711744 + H6013 as M8, re-spin the >>>> tests, solidify the build. >>>> >>>> I'm voting for (3). I would be glad to be proved wrong on my concerns, >>>> actually I would be pleased with that :) >>>> Maybe just arrange a vote again? >>>> >>>> Thanks, >>>> Aleksey. >>>> >>>> On Wed, Nov 12, 2008 at 3:39 PM, Tim Ellison <[EMAIL PROTECTED]> >>> wrote: >>>>> Aleksey Shipilev wrote: >>>>>> On Wed, Nov 12, 2008 at 2:17 PM, Tim Ellison <[EMAIL PROTECTED]> >>> wrote: >>>>>>> Can you think of a situation when the null check will introduce some >>>>>>> instability or regression? >>>>>> I actually persuaded by Chunrong's point -- that's double checking, so >>>>>> no problems should occur. >>>>>> >>>>>> As for introducing new bugs, consider the issue described in >>>>>> HARMONY-6013 is really covering some other deadly issue. Consider the >>>>>> workload where NPE is not firing because of H6013, >>>>> ...but the test doesn't silently work without the NPE, it causes a trap. >>>>> >>>>> So we know that our tests don't currently cover the situation where we >>>>> would now expect to get a NPE, or they would be trapping today, right? >>>>> >>>>>> so after H6013 gets >>>>>> fixed the control flow in that workload is going differ than in tested >>>>>> M8. As many uses of the helper, as many the chances the control flow >>>>>> differs. Having that, we can't say the change is minor. >>>>> I appreciate that the code will appear in many places, but I think it is >>>>> localized and we know the situation doesn't occur in current testing. >>>>> >>>>> That said, I'd rather run the two days + testing again rather than spend >>>>> two days arguing about it :-) >>>>> >>>>>> If I will be >>>>>> able eventually to say that similar changes are "limited >>>>>> impact"-issues, then you should employ me as oracle tester <g> :) >>>>> lol >>>>> >>>>>> Of course, that's the speculation if this is actually a double null >>> checking. >>>>>> I just want not to guess while talking about milestones. >>>>> ack - like I said, if people think we should re-spin the build and >>>>> retest, then I'm ok with that too. It would be the conservative >>> approach. >>>>> Regards, >>>>> Tim >>>>> >>> >>> >>> -- >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >>> >> >> >> -- >> Best Regards >> Sean, Xiao Xia Qiu >> >> China Software Development Lab, IBM >> >
