Commit responsibilities and Lines of Defense
Kelly O'Hair
kelly.ohair at oracle.com
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.
-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
More information about the build-dev
mailing list