Re: [gentoo-java] Java going GPL; Stallman approves -- News at 11:00

[David Herron]

Karl,

Thank you for informing me of this Eclipse working group.  I wasn't 
aware of it.  And reading the page you mentioned was very very very 
hauntingly like the issues that led us to creating the DLJ license and 
the jdk-distros project.

The jdk-distros project is meant to be a staging ground for some of the 
linux-specific bits and documentation.  However it's focused entirely on 
installers, and not the JDK code itself.  The jdk-distros project uses 
the BSD license to facilitate even more fluid code sharing.

You are probably talking about source changes, not installer changes..?

The current contribution process is a work in progress and we know it's 
not the final one.  We plan to develop a better contribution process 
over time.  The process that's there is very similar to the process we 
use in-house that Sun engineers go through on every change we make to 
Java SE.  We take stability as a very high attribute and the process we 
follow involves a lot of peer review and unit/etc testing before it is 
allowed into the central source repository.

But, that said, any future contribution process is open for discussion.  
The appropriate place to take that is the mailing lists and/or forums on 
java.net.

We are open to, in the future, having external contributors with direct 
putback rights.  And that, too, is a topic for discussion.

BTW, one goal for the jdk-distros project was for it to hold the 
installer scripts for each distribution using the DLJ.  The 
Debian/Ubuntu scripts are in the jdk-distros repository.  The Gentoo 
scripts could be, if you desire, if there is any need for it. 

The purpose was along the lines of what you have discussed.  To 
facilitate sharing between the distribution makers of the installation 
procedures.

- David Herron



Karl Trygve Kalleberg wrote:
> David Herron wrote:
>
>> Karl, I agree completely.
>>
>> We have been looking at this question for some time.  Clearly in the JDK
>> sources we have code that supports Linux, and we have code which
>> supports SPARC, but not these two at the same time.  It turns out to be
>> a little difficult to bring those two together.
>>
>
> I appreciate the engineering difficulties here, but I don't think they
> are insurmountable given some time, motivation and elbow grease.
>
>
>> I would think that in the not too far distant future there could be
>> project(s) like you say working together in the openjdk project to
>> support the JDK on new architectures and maybe new operating systems.
>> e.g. The Free BSD team and that ilk might want to collaborate with us
>> more directly now that our licenses are more open.
>>
>> How would *you* prefer that the collaboration would work?
>>
>> I know our preference is for the collaboration to be in the bounds of
>> the openjdk project site.  The governance and contribution procedures
>> are a work in progress at the moment.  You can see on the openjdk
>> project site the contribution process.  So, e.g., if you had a
>> Gentoo-specific source change to make, you could submit it through that
>> contribution process.
>>
>
> My experience with other projects, such as Eclipse, tells me that it
> would be preferable to have one common repository upstream (that's with
> you guys) for collecting and sharing patches used in the packaging process.
>
> It turns out that many patches used by distro A are also very useful for
>  distro B -- this is a pretty established fact by now. Another
> established fact is that we (the package maintainers on various distros)
> spend a lot of time digging through each other's repos and home pages
> looking for interesting patches for common problems. This is pure waste
> of time.
>
> With Eclipse, we're combating this with a new project, see
> http://www.eclipse.org/proposals/linux-distro/
>
> Basically, the Eclipse Linux Distro project is a staging ground for
> fixes/patches/improvements to Eclipse that are specific to Linux (I
> don't think we're against *BSD in any way -- they've just not been part
> of the process so far).
>
> The patches that end up in the Eclipse "Linux Distro" project will not
> be automatically placed into the main Eclipse code base. They will most
> likely simmer in the Eclipse Linux Distro for some time, and during that
> time, it's up to the various distros whether they want to apply it or not.
>
> Some patches might eventually make it into the main Eclipse code base,
> many won't. But even for those that won't, chances are that they'll be
> maintained as the main Eclipse code base evolves, since they are often
> shared across distros, and because maintainers from the various distros
> have accesss to the Linux Distro code base.
>
> Perhaps a similar model will work for the JDK (which is our primary
> concern ATM -- other projects like J2EE might follow), say a "JDK Linux
> Distro" subproject of the OpenJDK.
>
> However, it is vitally important to keep the barriers for accessing and
> working on the code base in such a JDK Linux Distro low. I wouldn't mind
> having to sign the necessary CAs to commit to the JDK Linux Distro
> subproject, but I *would* mind if some Sun engineer needs to bless my
> code every time I have a patch to share with the other packagers. "Patch
> blessing" should only be necessary when code is taken from the JDK Linux
> Distro staging ground and put into the OpenJDK proper.
>
>
> Since the Eclipse Linux Distro project is still in its infancy, it's too
> early to tell how well this model works, but if I were in the Sun JDK
> team, I'd keep an eye out for it and see how well it turns out to work.
>
> "A beginning is a very delicate time", as some fictitious princess once
> said.
>
>
> Cheers,
>
> -- Karl T
>