harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [DRL VM] classlib tests regressions - could we stop commits to DRL VM workspace
Date Mon, 04 Dec 2006 05:39:40 GMT
2006/12/1, Geir Magnusson Jr. <geir@pobox.com>:
> Nice work.  Can you now (and in the future) just add a note when you
> find the problem what the problem was?  it's much easier to create
> awareness and discussion if we can keep going in the same thread, rather
> than have to go find the commit message

Sure. The HARMONY-1925 patch regrouped properties initialization, and
reduced some of string manipulation operations. One of those was
calculation of a parental directory of a base directory for java
executable, which appears to be "java.home".
So the default values of "java.home" and "java.ext.dirs" pointed to
wrong location; while the first is reset to correct value by the
launcher, the last remains as is and any security providers happened
to be in extensions cannot be loaded.
Actually this is my bad that I failed to check with HUT such a big
change prior to commit, just relied on "build test"...

Another point is that properties initialization should be moved to
post-cmdline-parsing stage, to handle better such dependencies between
properties.

--
Alexey

>
> geir
>
>
> Alexey Varlamov wrote:
> > Fixed in r481188, please verify.
> >
> > 2006/12/1, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> >> Mikhail,
> >>
> >> I believe I found & fixed the root cause, running tests at the moment.
> >>
> >> 2006/12/1, Mikhail Loenko <mloenko@gmail.com>:
> >> > I've tried "merge -r 480913:480912"
> >> >
> >> > seems like everythung works fine. I'm rerunning the tests...
> >> >
> >> > 2006/12/1, Mikhail Loenko <mloenko@gmail.com>:
> >> > > Isn't waiting less costing? If we roll the changes back we can at
> >> least continue
> >> > > further commits. Of course if the reason is clear we should fix it.
> >> > > The problem is
> >> > > that we first broke one test, then one more and then hundreds
> >> more. That
> >> > > means that at least several of commits were broken
> >> > >
> >> > > Thanks,
> >> > > Mikhail
> >> > >
> >> > > 2006/12/1, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> >> > > > Guys,
> >> > > >
> >> > > > Shouldn't rollbacks be the last resort, as it was agreed? Don't
you
> >> > > > want to let a chance for primary investigation and hopefully
> >> quickfix?
> >> > > > Rollbacks are costly and somewhat demotivating...
> >> > > >
> >> > > > --
> >> > > > Alexey
> >> > > >
> >> > > > 2006/12/1, Mikhail Loenko <mloenko@gmail.com>:
> >> > > > > What is the last working revision? Let's roll back all the
> >> > > > > DRLVM changes since that
> >> > > > >
> >> > > > > 2006/12/1, Stepan Mishura <stepan.mishura@gmail.com>:
> >> > > > > > Hi,
> >> > > > > >
> >> > > > > > Today I see new failures (115) of classlib tests on
DRL VM.
> >> I didn't see
> >> > > > > > them yesterday . I'm going to find which commit caused
> >> regression and roll
> >> > > > > > it back. Could we stop committing new code to DRL VM
workspace?
> >> > > > > >
> >> > > > > > Stepan Mishura
> >> > > > > > Intel Enterprise Solutions Software Division
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

Mime
View raw message