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 1Gk4wK-0002JI-6k for garchives@archives.gentoo.org; Tue, 14 Nov 2006 20:31:28 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kAEKU0Ei008271; Tue, 14 Nov 2006 20:30:00 GMT Received: from rasmus.uib.no (rasmus.uib.no [129.177.13.13]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kAEKU0Rb005907 for ; Tue, 14 Nov 2006 20:30:00 GMT Received: from nille.uib.no (smtp.student.uib.no) [129.177.13.20] by rasmus.uib.no with esmtp (Exim 4.34) id 1Gk4us-0001WH-SS; Tue, 14 Nov 2006 21:29:59 +0100 Received: from apal.ii.uib.no ([127.0.0.1]) [129.177.16.81] by smtp.student.uib.no with asmtp (Exim 4.34) id 1Gk4us-000136-FL; Tue, 14 Nov 2006 21:29:58 +0100 Message-ID: <455A274E.5080902@gentoo.org> Date: Tue, 14 Nov 2006 21:30:06 +0100 From: Karl Trygve Kalleberg Organization: Genoo Foundation User-Agent: Thunderbird 1.5.0.7 (X11/20060918) 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 To: David Herron CC: Gentoo-Java Mailing List Subject: Re: [gentoo-java] Java going GPL; Stallman approves -- News at 11:00 References: <200611130008.24137.greg@tassone.net> <4558E44A.10806@ii.uib.no> <455904C7.5080705@sun.com> <455A01EA.2000209@gentoo.org> <455A0ECF.5000205@sun.com> In-Reply-To: <455A0ECF.5000205@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-checked-clean: by exiscan on rasmus X-Scanner: 76ea9cff80dd39436e17507c45c4e059 http://tjinfo.uib.no/virus.html X-UiB-SpamFlag: NO UIB: -9.4 hits, 8.0 required X-UiB-SpamReport: spamassassin found; -9.0 Message received from UIB -0.4 Did not pass through any untrusted hosts X-Archives-Salt: 46730ef3-156a-4ef9-bafe-f6bc7df901df X-Archives-Hash: f017cac97d8110ec71c0e3d379ec9d27 Hi David > 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..? Yes, I am referring to inevitable patches required to get the JDK built from source code, since that is what we want to do as soon as we can get around to it -- build the JDK from source code instead of using the Sun-provided DLJ binaries (of course, first all of the JDK must be there, c.f. the encumbered parts of the library). In the past, we had a from-source ebuild for the JDK, but given the (old!) licensing conditions, none of the current Gentoo Java developers wanted to become contaminated by looking at the JDK source (this is now a thing of the past! waaaay!). In our from-source ebuild, we did various patching (I don't know the specifics) of the JDK source to get it built on Gentoo. Similarly, for Eclipse, we've had to do all kind of strange code acrobatics to get it compiling even remotely properly on Linux. Over the years, Eclipse has been able to use the Motif and Gtk+ windowing toolkits, the GNOME and KDE VFS, the Mozilla embedded browser component (libgtkembedmoz), and it has been rather picky about which Java compilers and JDKs it will build with. Since Eclipse doesn't use autoconf and friends, and some of the build paths have even been hardcoded to fixed paths in their buildfarm, it's sometimes been a bit icky to get everything compiling smoothly for our users. Take the example of the embedded HTML component in Eclipse, which uses the Gecko rendering engine. Upstream, this component has historically either been built against the Gecko SDK or one of the Mozilla 1.x stable branch, but upstream doesn't maintain compatibility for both. So, we've had to patch in support for compiling Eclipse on systems where only Firefox is installed (and this is possible, even though the label advises against it;). Since I've not yet familiarized myself with the JDK source base, I cannot offer specific examples of where we would need to patch your build scripts, but I am sure we'll run into something pretty quickly, and so will the Debian, Fedora, OpenSUSE and Ubuntu guys, I am sure. > 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. That is perfectly understandable, and I would have it no other way. Your goal is to ship stable products and be the primary care takers of the JDK code base. What we need is a place and a forum where we can share build system patches and fixes (and sometimes, the patches may affect more than just the build system -- even you guys make a few mistakes and incorrect assumptions in your code now and again;). > 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. I think I should be clear that I'm not asking for you to loosen your standards when it comes to the commit privileges on the OpenJDK repository. I do see the need for an arena with a code repo, a wiki, a mailing list where the JDK packagers on the various distros can share code, ideas, gripes and experience. > 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 jdk-distros project may indeed be exactly what we're looking for here. I don't think that there's any point in us putting our ebuilds into this repo, however, because they would grow stale in a matter of days -- as you know, we try to maintain all our installation scripts (i.e. ebuilds) in the Portage tree, so that they're always and instantly available to our users. Any patches and fixes that we eventually apply to the JDK built system, however, are candidates for inclusion into jdk-distros. > The purpose was along the lines of what you have discussed. To > facilitate sharing between the distribution makers of the installation > procedures. Perhaps expanding the mandate for jdk-distros is useful, then, to also include build system patches for the OpenJDK. Since Gentoo is "from source"-outfit, our focus will shift towards source drops of the JDK as these become available (hopefully some time next year) and Java 1.7 draws closer to a release. I anticipate that we will keep Sun-provided binaries for 1.5, 1.6 and 1.7, and probably even future versions in the years to come, but our priority has always been and will always be source-based packages. (But I'm not the cat-herder around here anymore, so my thoughts on the binary/source issue are just speculations based on hard-earned experience, and should not be taken as any official statement on behalf of the Gentoo Java Team.) Cheers, -- Karl T -- gentoo-java@gentoo.org mailing list