Hadrian, thanks for the excellent summary. Best, Christian
On Fri, Sep 28, 2012 at 11:45 PM, Hadrian Zbarcea <hzbar...@gmail.com>wrote: > I though Ross was very clear in his explanation, but apparently not... > <rant please-ignore="true">**Unfortunately this thread (happens too often > at the ASF) is digressing into hypothetical, vague and philosophical > discussions.</rant> > > Quoting Ross: "this *is* completely different". As an aside, I personally > don't consider subscribing a private@ PMC mailing list to another list > the smartest thing to do, I'd rather have individual PMC members subscribe > and inform the rest of the PMC. That however doesn't cause any issue > because, quoting Ross again, that's just a "communication link". I would > add that that is a unidirectional communication link, by which the external > project communicates something of interest to an audience, and a PMC > happens to be part of said audience. The PMC is a *passive* participant. > > This is not the case of the camel-extra project. Apache Camel is an > integration framework. Its intent is to simplify integration by providing a > common API and bridging glue components for a large number of protocols and > data formats. The specific protocol implementations however come from 3rd > party libraries. For most of the technologies of interest, Camel found/uses > libraries with a compatible license. The camel-extra project was created to > extend the reach of Apache Camel to technologies available under > non-compatible licenses (e.g. xGPL). The project was started and controlled > by Camel committers on google code and later moved to apache-extras (kinda > the same thing). The camel-extra project was never governed as an ASF > project from many points of view, including oversight, release process and > IP management. The project had committers who are not ASF committers for > instance. The Apache Camel committers have control over the project and are > *active* in the government of the project *as individuals* (albeit not > completely following the ASF guidelines). This is the difference. > > There is a (valid) perception that the camel-extra is an extension of the > Apache Camel project. That was fueled by the fact that some camel-extra > components are documented on the ASF camel site. This thread was actually > started by an enthusiastic request of a new Apache Camel committer on the > premises that "it would be nice if" Apache Camel were a one stop shop for > both projects/communities. I.e. why work in 2 places, 2 sets of > infrastructure, etc, when Apache Camel is already the > established/recognized one. While it would be nice for users indeed, it is > not compatible to the way the ASF operates. (To use your analogy, think > more like the LibreOffice community operating from within the Apache > OpenOffice community, using the same site and mailing lists). > > FWIW, this was mentioned on the camel lists, but that was probably not > considered enough. Christian, the Camel PMC chair, knowing full well the > dynamics of the community, did the right thing and decided to forward the > question/request to a more authoritative forum. In the meanwhile the Camel > community got the message from all replies in this thread (I think) and the > changes currently made to the camel-extra project reflect the differences > between the two communities. However the thread lingers on on this list... > > I hope this clarifies the current status a bit better. > Hadrian > > > > On 09/28/2012 03:44 PM, Rob Weir wrote: > >> On Fri, Sep 28, 2012 at 4:13 AM, Ross Gardler >> <rgard...@opendirective.com> wrote: >> >>> On 28 September 2012 02:41, Rob Weir <robw...@apache.org> wrote: >>> >>> ... >>> >>> Specific example. OpenOffice podling has signed up for a security >>>> mailing list where we receive security-related bug reports from >>>> LibreOffice, an open source project that is LGPL/MPL, not ALv2. We do >>>> this by subscribing our security list directly to theirs. Is this >>>> against policy? This seems directly analogous to a project receiving >>>> bug reports from a non ALv2 Apache Extras project. >>>> >>> >>> This is completely different. LibreOffice is a separate project with a >>> separate infrastructure and community. The subscription of an ASF list >>> to a LibreOffice list is nothing more than a communication link >>> between two distinct entities. The proposal here is to not create a >>> separate project with a separate management structure but to simply >>> host incompatible code externally and manage it from within an ASF >>> PMC. >>> >>> >> Exactly my point. To the question put earlier: >> >> "whether mailing list connections and other conveniences would create >> unacceptable confusion >> about the distinction between 'things the PMC does' and 'things some >> PMC members happen to do elsewhere.'" >> >> IMHO, the mailing list connections are not the issue. The issue is >> the relationship between the Apache Extras project and the Apache >> projects. If the relationship is improper, from a control and >> dependency perspective, then that is the problem. The mailing list >> use connection does not create the problem. And I suspect that >> avoiding the mailing list connections would change nothing fundamental >> if there were a control and dependency issue. >> >> Regards, >> >> -Rob >> >> Ross >>> >>> -- >>> Ross Gardler (@rgardler) >>> Programme Leader (Open Development) >>> OpenDirective http://opendirective.com >>> >> --
