Commit responsibilities and Lines of Defense

Kelly O'Hair kelly.ohair at oracle.com
Mon Feb 21 20:01:13 UTC 2011


On Feb 21, 2011, at 1:29 AM, Andrew Haley wrote:

> On 02/18/2011 10:09 PM, Kelly O'Hair wrote:
>
>> But there have been some roadblocks for the open source community.
>>
>> It has been observed (for a long time now) that:
>> * The Mercurial jcheck extension needs to be open sourced
>> * The bug tracking system needs to be completely open
>> * We need an open build and test system for the OpenJDK developers  
>> who don't have access to all the systems
>>
>> We are working on it. And of course you have heard that before, but  
>> we are, really.
>
> That's very good news, especially the bug tracking system.  I thought
> that the plans to open that up had been abandoned with the Oracle
> acquisition of Sun.

No, we just have a different internal bug tracking system to interface  
with now.
I've asked the person in charge to consider discussing the plans more  
publicly.

>
>> It's that last item that involves myself and a group of Oracle  
>> engineers in Stockholm, hopefully we
>> can come up with a solution that works for everybody. I have  
>> tentatively named it BAT for
>> Build And Test, but it is just in the infancy stage, nothing  
>> official yet. But we would like some input.
>>
>> The intent would be to accept repository paths, tips, and changeset  
>> bundles or diffs (for test runs),
>> run it through a matrix of builds and tests, and return back status  
>> or even do the Push if requested.
>> Internally, we have such a system, but it's not clear exactly how  
>> much we can reuse.
>>
>> Due to the proprietary nature of some of the tests and systems, and  
>> also a need for security, it's not
>> exactly clear how much data we can expose. But we should be able to  
>> run selected and critical tests for
>> everyone, and of course verify there have been no build issues  
>> introduced by a change.
>
> Fabulous.
>
>> When all goes well, that is one thing, but when it doesn't and non- 
>> open tests fail, then it gets tricky.
>> (yeah yeah we should open source the tests, that just can't happen  
>> in all cases).
>
> It'll be tricky if some crucial flaw is revealed by a private test.  I
> suppose in that case that an Oracle engineer will have to analyse the
> problem.

Yes, and at that point the question will be, 'can we open up this  
test' or 'can we find an open replacement'
or 'can we at least create an isolated testcase we can make open'.

>
>> It is clear to us that we cannot make the system entirely "open",  
>> but we can provide a kind of portal
>> (I hate that word), or view (a better word) into what is happening.  
>> Exposing what we legally can and
>> hopefully providing enough information to make the system work for  
>> everyone.
>>
>> So what do you think? Any opinions out there?
>
> This sounds like a big step forward, and a great way to show everyone
> that Oracle is determined to work with the community.

We recognize that a model where all changes must be shepherded through  
by an Oracle employee
will not scale, so we are being motivated by a bit by how we can make  
it a true community
contribution situation and also not overload the Oracle engineers with  
needless shepherding tasks.

Of course I have to clarify,
   The views expressed in this email are my own and do not necessarily  
reflect the views of Oracle.

Everything does take time. ;^)

-kto

>
> Andrew.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110221/5f1546ed/attachment.html>


More information about the build-dev mailing list