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
