public inbox for gentoo-java@lists.gentoo.org
 help / color / mirror / Atom feed
From: David Herron <David.Herron@Sun.COM>
To: Karl Trygve Kalleberg <karltk@gentoo.org>
Cc: Gentoo-Java Mailing List <gentoo-java@lists.gentoo.org>
Subject: Re: [gentoo-java] Java going GPL; Stallman approves -- News at 11:00
Date: Tue, 14 Nov 2006 10:45:35 -0800	[thread overview]
Message-ID: <455A0ECF.5000205@sun.com> (raw)
In-Reply-To: <455A01EA.2000209@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 5725 bytes --]

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
>   

[-- Attachment #2: Type: text/html, Size: 6279 bytes --]

  reply	other threads:[~2006-11-14 18:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-13  8:08 [gentoo-java] Java going GPL; Stallman approves -- News at 11:00 Greg Tassone
2006-11-13 11:46 ` Xavier MOGHRABI
2006-11-13 12:07 ` Boris Dušek
2006-11-13 12:37   ` Samuel Penn
2006-11-13 15:56 ` David Herron
     [not found]   ` <4558E44A.10806@ii.uib.no>
2006-11-13 23:50     ` David Herron
2006-11-14 17:50       ` Karl Trygve Kalleberg
2006-11-14 18:45         ` David Herron [this message]
2006-11-14 20:30           ` Karl Trygve Kalleberg
2006-11-14  0:49 ` Andrew Cowie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=455A0ECF.5000205@sun.com \
    --to=david.herron@sun.com \
    --cc=gentoo-java@lists.gentoo.org \
    --cc=karltk@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox