harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [vote] Declare r711744 as M8
Date Thu, 13 Nov 2008 13:57:14 GMT
+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