On Feb 21, 2011, at 6:28 PM, Dr Andrew John Hughes wrote:
On 18:08 Mon 21 Feb , Kelly O'Hair wrote:
On Feb 21, 2011, at 1:33 PM, Dr Andrew John Hughes wrote:
snip
So this is going to be yet another system? What will happen to the
existing
pretty much unused OpenJDK bug database?
It's not clear. The old Sun bugtraq system was closed but we had some
ability to expose information.
The Oracle bug system is very closed, so the requirements have
changed
with regards to how the open and
closed interact together.
Before we mostly worked with Sun bugtraq, some public exposure, and
slightly augmented by the openjdk bugzilla.
(and we did a poor job of watching over the bugzilla system, sorry).
In the future it may be more that everyone is using the open system
(whatever that is), and only augmented
by the closed system when needed. Bottom line is that this is a good
thing for the open side,
but I have no idea what that open system will be at this time. It's a
plan for a plan, and in progress.
I think when this gets rolled out, other than perhaps people not
liking the particular implementation that
might get picked, the open world will be better off because it will
be
THE default bug tracking system.
So I take it the previous democratic choice of Bugzilla may be
ignored?
Don't know what to tell you on this, I'll crawl back under my BAT rock
now and hide. ;^{
Of course I have to clarify,
The views expressed in this email are my own and do not necessarily
reflect the views of Oracle.
snip...
I think if any of these tests become issues, we can address it then.
Like I said, it may be this event that triggers the discussion on
what
we should be doing
in terms of opening up a test, or not requiring a test be run.
I'd rather the proprietary tests weren't part of the open system to
begin with.
Waiting until they cause a problem and then waiting for that problem
to be
resolved is an issue we can foresee now and could easily sidestep by
not
including proprietary tests.
I understand your point of view, but if indeed one of these tests
fail, it is very very
likely to be a VM or jdk regression, so from my perspective, I'd
rather find this out
before the openjdk change is integrated rather than later after we
start testing jdk7.
So even though a test failure can't be completely analyzed in the
open, the actual running
of the test does have a great deal of value to us.
snip...
The primary tests we would run to start with the jdk repository
would
be the regression
tests in the repository, at least that's what I was thinking.
Adding
in mauve might be next?
The VM tests used are the trickier ones.
That sounds good. Merely doing builds, never mind tests, on
platforms
such as Windows, Solaris and Mac OS X will be an advantage.
To be completely upfront, there is a catch, it's not clear to me
whether the actual built bits can
be returned yet, in amm os-arch cases. That's a legal issue I need to
resolve.
I don't have a problem with it, but I need to make sure it's ok. So
initially, all you might get back
are the build logs and a success/failure indication, I'll work on the
getting the built bits back,
but no promises.
From my perspective, I'm happy if it builds and we don't get
regressions.
The resulting binaries for a system I don't have anyway aren't much
use :-)
I imagine there will be some desire for them from other corners
though.
OK, good to know.
Will OpenJDK6 also be covered by this scheme? At the moment,
results
for it are of greater value for most people than those for the
unreleased OpenJDK7.
I'll allow for OpenJDK6, but we may need to play with what the
configurations are
for building and testing, e.g. the os-arch-compiler combinations to
build and test.
Yes, I guess that's to be expected.
Of course I have to clarify, again ;^)
The views expressed in this email are my own and do not necessarily
reflect the views of Oracle.
-kto
Thanks for working on this,
Hopefully I can get some traction on this soon.
-kto
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
