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 1HhXMb-000664-Ou for garchives@archives.gentoo.org; Fri, 27 Apr 2007 20:48:22 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l3RKlIIb011033; Fri, 27 Apr 2007 20:47:18 GMT Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l3RKlIZu011016 for ; Fri, 27 Apr 2007 20:47:18 GMT Received: by ug-out-1314.google.com with SMTP id z38so818498ugc for ; Fri, 27 Apr 2007 13:47:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QZTlUma5kfbwwsjoz9VS438tOGH7Mya8EjqNcw3LIsiXm0WDsc3t2bk/ibZh166RBRoVeTUwmSYAU+7uF6onfEWvHoA9Gqxr7NyLsMrA8kAEcGIhCLhH7rZNdH8f4ymtTgL56WTKRVq1LgUhjVZ+/gbyFOl6P6BTrEg2oNwEwvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bAfH7OmZqL+RMKQNPgejUX5cTlhzdcq4XnvReAXSy+fhkGvQkYGKJ2MDeW4NvTDlg9lx897N4QNlJ/fyAeu1I0dDt5rWmyJ9zmEsRkrlAjQYO/IB3TIhFIeJBvWy3JfSKJNz2UIBXYh1em4ywq4RZwYTC/s8DH0TuZ95NLRejVY= Received: by 10.66.248.13 with SMTP id v13mr3251328ugh.1177706838022; Fri, 27 Apr 2007 13:47:18 -0700 (PDT) Received: by 10.67.14.6 with HTTP; Fri, 27 Apr 2007 13:47:17 -0700 (PDT) Message-ID: Date: Fri, 27 Apr 2007 21:47:17 +0100 From: "robert burrell donkin" To: gentoo-java@lists.gentoo.org Subject: Re: [gentoo-java] Want to affect how JSRs are developed? In-Reply-To: <4630EED4.6030206@kaffe.org> 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: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <4630EED4.6030206@kaffe.org> X-Archives-Salt: 04b99781-7ad3-4483-8119-9c23d33a1b20 X-Archives-Hash: e046f6a8831804bf7bfe6cc11738f615 On 4/26/07, Dalibor Topic wrote: > 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. legal clarity is a powerful tool > >> 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. one reading of history would be that the EC inducted into it's number those organisations they discovered they needed to care about. not sure that i believe that this is the truth or that the participants would see it in those terms. the key difference is that they have never had to care about or deal with downstream organisations before some good points > 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. not sure i agree with this my guess is that it has more to do with acknowledgment of the necessity of change. the current process is a complex compromise which is less than ideal for any of the parties but which most players used to think was good enough. it's been reasonably successful in practice. the withdrawl of JEE6 suggests that there's a wider malaise than just the apache-sun dispute over harmony. it's often the case that outsiders can see solutions than insiders cannot. > 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. but approach this is hamstrung by the fact that the JCP is short of formal feedback mechanism. the JCP needs more confidence in itself and open up. > 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. this is easier for downstream packagers than open source implementors. implementations have to begin before the specification is complete. for this to work, implementors need greater legal clarity at the outset. that way, they can ignore closed JSRs. > >> 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 can only think of a handful which were actually lead by apache members at the time when they were 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. my guess is that there isn't a single answer to this question and that motivations vary with time a few years ago, it wasn't really possible to develop JSRs within apache: projects are not allowed to discriminate between those committers who have signed NDAs and those who have not. so, mostly RIs were donated at the end of the process. my guess is that the TCK remained closed either to preserve revenue streams or just through inertia. it is now possible to create a specification within apache (see http://db.apache.org/jdo/) using open methods. in this case, the TCK and specification were homed at apache and the RI at codehaus. maybe this implies that there is some sort of operational advantage in splitting RI from TCK teams. - robert -- gentoo-java@gentoo.org mailing list