Commit responsibilities and Lines of Defense

[Kelly O'Hair]

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.

>
>>   * 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.

>
>>   * 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 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.

>
> 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.
I agree open tests are preferred.

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

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.

-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