harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [vote] Declare r711744 as M8
Date Thu, 13 Nov 2008 14:03:37 GMT
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 <sean.xx.qiu@gmail.com> 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 <sianjanuary@googlemail.com>
>>
>>> 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 <aleksey.shipilev@gmail.com>:
>>>> 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 <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
>>>>>
>>>
>>>
>>> --
>>> 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
>>
> 

Mime
View raw message