harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "chunrong lai" <chunrong...@gmail.com>
Subject Re: [vote] Declare r711744 as M8
Date Fri, 14 Nov 2008 01:54:02 GMT
 +1 to start a vote for r713673.

On Fri, Nov 14, 2008 at 12:57 AM, Sian January
<sianjanuary@googlemail.com>wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message