Commit responsibilities and Lines of Defense

Kelly O'Hair kelly.ohair at
Tue Feb 22 04:35:09 UTC 2011

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.


> -- 
> Andrew :)
> Free Java Software Engineer
> Red Hat, Inc. (
> Support Free Java!
> Contribute to GNU Classpath and IcedTea
> PGP Key: F5862A37 (
> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

More information about the build-dev mailing list