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.62) (envelope-from ) id 1Hh8gK-00026T-DS for garchives@archives.gentoo.org; Thu, 26 Apr 2007 18:27:04 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l3QIQV4e007370; Thu, 26 Apr 2007 18:26:31 GMT Received: from interferon.mpi-sb.mpg.de (mx.mpi-sb.mpg.de [139.19.1.1]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l3QIQU6Q007365 for ; Thu, 26 Apr 2007 18:26:31 GMT Received: from localhost.mpi-sb.mpg.de ([127.0.0.1]:48266 helo=localhost ident=amavis) by interferon.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.50) id 1Hh8fk-0007mZ-6w; Thu, 26 Apr 2007 20:26:28 +0200 Received: from interferon.mpi-sb.mpg.de ([127.0.0.1]) by localhost (aspirin.mpi-sb.mpg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27443-09; Thu, 26 Apr 2007 20:26:28 +0200 (CEST) Received: from mpiat2312.ag2.mpi-sb.mpg.de ([139.19.20.101]:51879) by interferon.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.50) id 1Hh8fj-0007mP-KD; Thu, 26 Apr 2007 20:26:27 +0200 X-Notes-Item: NOT CHECKED; name=$DNSBLSite Message-ID: <4630EED4.6030206@kaffe.org> Date: Thu, 26 Apr 2007 20:26:28 +0200 From: Dalibor Topic User-Agent: Icedove 1.5.0.8 (X11/20061128) 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: robert burrell donkin CC: gentoo-java@lists.gentoo.org Subject: Re: [gentoo-java] Want to affect how JSRs are developed? References: <4628E974.6030500@gentoo.org> <1177266176.32607.5.camel@wlt.obsidian-studios.com> <1177436449.3524.9.camel@wlt.obsidian-studios.com> <462D2E0C.6090200@kaffe.org> <462F4289.9050401@kaffe.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mpi-sb.mpg.de X-Archives-Salt: b36d4619-e325-4dc0-b0af-777d7033d48a X-Archives-Hash: 9385346a178947d549469af7049efe8e robert burrell donkin wrote: > On 4/25/07, Dalibor Topic wrote: >> * no one can force the spec leads to do the right things, even if the >> whole EC was replaced instantly. > > this one is solvable. spec leads just need to be forced to issue > public licenses up front at the start of the process rather than > relying on hub-and-spoke contracts with participants. Good idea, but in practice nothing prevents a spec lead from having further license arrangements on their output, afaict, so I don't think that hub-and-spoke contracts will go away (or that spec leads would want to limit their own licensing options that way, in general). I'd suggest advancing that idea on the merit of clarity of legal arrangements around a JSR, rather than as a means of forcing the spec leads to behave in a specific way. >> I don't think that the confrontational 'let's make noise inside the JCP' >> approach would work for us who aren't on the EC, and that's pretty much >> everyone. > > +1 > > but FOSS people setting out better ways to run standards processes may > well make a difference. in particular, the downstream perspective is > completely missing from the current debate. That's correct, but I don't think that the EC membership has so far cared that much about the perspective outside their own organizations ... yet. That's not a particular surprise, since people on the EC will largely push the agendas of the organizations they belong to, after all they are (for the most part) paying for the privilege of getting their products turned into standards, and being able to influence the standardization process. There is a simple fix, though: Sun seems to have figured out that cooperating with downstreams can be benefitial for them, and that cooperation will likely lead to some benefits for Sun in terms of how ubiquitous their technologies will be deployed/deployable downstream, as the downstreams really like Free Software & transparency and all the other sane engineering stuff. The way Sun goes is the way the rest of the EC will follow, if it turns out to work for Sun. Proposals to change the JCP process have been discussed regularly outside the JCP, but in general have not resulted in changes of the processes. We could speculate why that's the case, but afaict, directly changing specifics of the process from outside does not really work. One can discuss ideas to do things in a better way, but at the end of the day it's up to the spec leads to adopt them or not. I'd suspect that the main reason for the lack of adoption of proposals to improve the JCP from outside the process comes from them being made outside the process, rather than by those inside the process. So I think it's more effective to have positive feedback for JSRs run reasonably, than to try from outside to teach spec leads how they should run their JSRs, or to force them to do specific things. What works is the 'market' supporting the specs that are well done, and ignoring those that aren't. Ignoring intransparently run JSRs is cheap and easy, and they ignore us anyway, so no harm done. >> I'd rather suggest that the >> ASF gets going working on creating open source TCKs for all RIs >> implemented under its spec leadership (the whole XML & WS-* stuff, >> Tomcat, and all that). > > i can't find any spec lead by apache on http://www.jcp.org/en/jsr/all My apologies for that assertion, I was mistakenly under impression that the ASF was leading specs, rather than individual companies whose spec leads happen to be ASF's members. > i agree that there are many specifications which were and are strong > influenced by apache ethos. apache has also been home to a lot of > reference implementations. but this is personal, not official. Is the reasoning why the ASF has been home to a lot of reference implementations without being the home for their test suites documented somewhere? I'm curios what motivates the persons using Apache as the home for their RIs to not develop their TCKs inside Apache. cheers, dalibor topic -- gentoo-java@gentoo.org mailing list