Commit responsibilities and Lines of Defense
Kelly O'Hair
kelly.ohair at oracle.com
Tue Feb 22 02:08:52 UTC 2011
On Feb 21, 2011, at 1:33 PM, Dr Andrew John Hughes wrote:
> On 18:29 Fri 18 Feb , Kelly O'Hair wrote:
>>
>> On Feb 18, 2011, at 4:29 PM, Dr Andrew John Hughes wrote:
>>
>>> On 14:09 Fri 18 Feb , Kelly O'Hair wrote:
>>>> <snip>
>>
>>>> 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
>>>
>>> Funnily enough, I just mentioned that in my reply to your mail about
>>> the jdk6 changesets... :-)
>>
>> Hopefully we will hear some good news on this soon.
>>
>
> That'd be good.
>
>>>
>>>> * The bug tracking system needs to be completely open
>>>
>>> Definitely. Making OpenJDK bug DB IDs usable in changesets would be
>>> a good start (probably involves jcheck...)
>>
>> I'll have to punt on that, someone else is working on it, but the
>> intent is to have a
>> completely open bug tracking system that also allows us link it with
>> the internal Oracle
>> bug tracking system. Once we have that defined, jcheck can be
>> adjusted
>> to use those numbers
>> or IDs. I don't think all the details are worked out. I'll see if I
>> can ping someone to make
>> some of the planning more public.
>>
>
> 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.
Of course I have to clarify,
The views expressed in this email are my own and do not necessarily
reflect the views of Oracle.
>
>>>
>>>> * We need an open build and test system for the OpenJDK developers
>>>> who don't have access to all the systems
>>>>
>>>
>>> This is especially important for Windows as I have no idea if
>>> anything I do breaks it and
>>> no way of doing builds on it. I expect the same to be true when Mac
>>> OS appears as a target.
>>
>> Yup. The number of platforms is going up, which makes it even more
>> important.
>>
>>>
>>>> <snip>
>>
>>>
>>> How much can be opened?
>>
>> Currently the parts that can't be opened that I can think of off the
>> top of my head:
>> * Closed builds or builds that include both the open changes and
>> the private Oracle repositories for JDK7
>> * Certain VM tests that are publicly available, like SPEC
>> benchmarks
>> * Certain VM tests that are Oracle private, but have been
>> historically run to verify VM stability
>> * Some closed jdk regression tests, security and otherwise
>>
>
> The first two mainly sound like things that matter to Oracle.
> Breaking
> Oracle's proprietary product is not ideal, but something only really
> Oracle
> can deal with and not the rest of the community. I presume the SPEC
> benchmarks
> would catch performance degradations; this would be useful, but not
> too helpful
> if you can't make the results public. I don't see how either could
> ever be made
> public so I think it's best to keep them separate from the open
> system.
Actually, these SPEC benchmarks are mostly used to verify correctness
in the builds.
They do a good job of self checking their results, and triggering lots
of VM actions
to happen when they run, so they actually serve as good stability tests.
Kind of like stress tests.
>
> The latter two also need to be kept separate to begin with, but I
> hope Oracle
> will be able to make these open at some point in the future.
I can't promise anything like that, but I suspect if a particular
testcase or testsuite becomes
a good bug finder, some developer may decide to try and open it up
just to make life easier
for everyone. Probably a case by case situation.
>
>> The general feeling is that we would not allow people to login to
>> these systems, but we
>> could provide complete specifications on what systems we are using.
>> Providing systems for OpenJDK people to access is not something we
>> are
>> thinking about.
>> Internally, it's rare that the exact same systems used like this are
>> needed by the developer.
>>
>> My preference is that other than the above items, any developer
>> should
>> be able to build
>> and test themselves on their platform, via the Makefiles in the
>> repositories, e.g. make all test.
>> And for the most part, the BAT system would just repeat the same
>> procedures the developer
>> can do on many other systems and in a distributed fashion for fast
>> turnaround.
>>
>
> Will any OpenJDK developer be able to submit a job to this system?
> If not,
> then it again creates a reliance on Oracle developers as we already
> have
> with the Oracle bug DB and the JPRT system.
The idea is that any OpenJDK developer with commit rights could submit
to the system.
Ultimately we want to allow for anybody to:
* File/edit/change a bug in a bug tracking system
* Get reviews from any OpenJDK user with commit rights
* Use the jcheck extension to verify changesets prior to push or
submit into a build&test system
* Submit proposed or final changes to a build&test system
No required Oracle assistance, other than getting commit rights and
informal approval
from the team that owns the destination repositories.
>
>>>
>>> From my stand point, I'd much rather we had the system completely
>>> open
>>> with those tests that can be made so, with appropriate direction in
>>> how to improve things and "fill in the holes". A bit like OpenJDK
>>> and
>>> the 'plugs'. Improving that is achievable, and expanding the
>>> range of
>>> open tests would be some good low-hanging fruit for the OpenJDK
>>> project. It would also establish a good set of JDK tests that can
>>> be
>>> used elsewhere. This is what we tried to do with Mauve
>>> (http://sourceware.org/mauve/).
>>
>> I would like to include mauve tests as part of the testing, if we can
>> fit it in.
>
> That's be great.
>
>> I agree open tests are preferred.
>>
>
> As I say, I don't see much point in anything else. What use are tests
> we can't discuss? How can we even trust their results?
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.
>>>
>>> Working with proprietary tests doesn't really help. It doesn't tell
>>> me
>>> anything if a test passes if I don't know what that test is; I don't
>>> know
>>> what exactly is being tested and whether I should trust the test at
>>> all.
>>> I already have some experience of working with such tests via the
>>> TCK
>>> and it's been much more of a hinderance than a help, especially when
>>> we can't openly discuss tests and their results. If I can't get a
>>> commit into OpenJDK because some test I can't look at is failing,
>>> it's just going to make me not want to bother trying.
>>
>> I understand the frustrations with TCK. But TCK is generally not what
>> we need
>> at the developer stage. I'd be more interested in running mauve than
>> TCK.
>> TCK is something that might get run at Integration time in my
>> opinion.
>>
>
> I wasn't suggesting we run the TCK; far from it. I was merely using
> it
> as an example of how NOT to setup this system :-)
Ah. Gotcha.
>
>> 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.
> 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.
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
>
>> -kto
>>
>>
>>>
>>>>
>>>> -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
>>
>
Of course I have to clarify,
The views expressed in this email are my own and do not necessarily
reflect the views of Oracle.
:^)
-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20110221/06bd1cfe/attachment.htm>
More information about the build-dev
mailing list