Yes. It is my final version, as the option (2) we discussed before. I just checked the snapshot uploading. The linux snapshots have been uploaded while the windows snapshots have not. Thanks. On Thu, Nov 13, 2008 at 10:03 PM, Tim Ellison <[EMAIL PROTECTED]> wrote:
> 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 > >> > > >
