harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [vote] Declare r711744 as M8
Date Wed, 12 Nov 2008 12:57:06 GMT
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?


On Wed, Nov 12, 2008 at 3:39 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Aleksey Shipilev wrote:
>> On Wed, Nov 12, 2008 at 2:17 PM, Tim Ellison <t.p.ellison@gmail.com> 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

View raw message