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? > 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. 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. > > 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, -- 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
