harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [DRL VM] classlib tests regressions - could we stop commits to DRL VM workspace
Date Mon, 04 Dec 2006 16:59:02 GMT
Vladimir,

I wonder why CruiseControl didn't show the problem with java.ext.dirs?
This was broken on Friday, and we got clear reports all weekend. Was
signed.bcprov.jar on CLASSPATH?



On 12/4/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> 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
> > >> > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>


-- 
Thank you,
Alexei

Mime
View raw message