harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sian January" <sianjanu...@googlemail.com>
Subject Re: [vote] Declare r711744 as M8
Date Thu, 13 Nov 2008 16:57:53 GMT
Thanks Chunrong.

It looks like all the snapshots are now available and the integrity
tests have been run on the latest revision
(http://people.apache.org/~chunrong/harmony-integrity/), with the same
results as r711744.

Shall we start a new vote for r713673, or does anyone need a bit
longer to try it out?


2008/11/13 chunrong lai <chunronglai@gmail.com>:
> 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 <t.p.ellison@gmail.com> 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 <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
>> >>
>> >
>>
>



-- 
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

Mime
View raw message