From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Gk3J3-0006Es-1d for garchives@archives.gentoo.org; Tue, 14 Nov 2006 18:46:49 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kAEIjdNM002395; Tue, 14 Nov 2006 18:45:39 GMT Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kAEIjb9A031006 for ; Tue, 14 Nov 2006 18:45:38 GMT Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kAEIjZHb027493 for ; Tue, 14 Nov 2006 11:45:36 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J8Q00C01HAN1Z00@mail-amer.sun.com> (original mail from David.Herron@Sun.COM) for gentoo-java@lists.gentoo.org; Tue, 14 Nov 2006 11:45:35 -0700 (MST) Received: from [129.145.161.79] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J8Q009DWHFYWMP6@mail-amer.sun.com>; Tue, 14 Nov 2006 11:45:35 -0700 (MST) Date: Tue, 14 Nov 2006 10:45:35 -0800 From: David Herron Subject: Re: [gentoo-java] Java going GPL; Stallman approves -- News at 11:00 In-reply-to: <455A01EA.2000209@gentoo.org> Sender: David.Herron@Sun.COM To: Karl Trygve Kalleberg Cc: Gentoo-Java Mailing List Message-id: <455A0ECF.5000205@sun.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@gentoo.org MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_uW06TF9AO7O3FlA6WA4U2A)" References: <200611130008.24137.greg@tassone.net> <4558E44A.10806@ii.uib.no> <455904C7.5080705@sun.com> <455A01EA.2000209@gentoo.org> User-Agent: Thunderbird 1.5.0.8 (X11/20061025) X-Archives-Salt: 8214d451-95be-4685-ae71-78e5ee607f23 X-Archives-Hash: fff3aa45960c94ff238d7da6910294cd This is a multi-part message in MIME format. --Boundary_(ID_uW06TF9AO7O3FlA6WA4U2A) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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 > --Boundary_(ID_uW06TF9AO7O3FlA6WA4U2A) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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
--Boundary_(ID_uW06TF9AO7O3FlA6WA4U2A)-- -- gentoo-java@gentoo.org mailing list