>From my perspective, the incubator isn't a loophole around the meritocracy approach of existing TLPs. Submitting a couple of patches can't be to high a barrier for people new to the ASF and the code base.
We regularly vote people in as committers if they contribute to felix subprojects and typically, if we accept a larger piece of code as a donation, we try to get the creator as a committer too. We did this with Karaf recently. I think felix is an excellent place for consolidating OSGi spec-related development here at Apache since the community is in place and very active. regards, Karl On Wed, Sep 2, 2009 at 5:29 PM, Guillaume Nodet<gno...@gmail.com> wrote: > We have in this proposal a lot of people who are not felix committers and > who are not even apache committers at all. > > They want to work on some code and create a community around it. The way > the ASF works means that the incubator is the right place to do so. The > only other solution is to develop it in a closed source environment and > submit it at Apache when it's done, and i really don't think it's a good > idea, given the willingness to do it in open source. > The blueprint implementation has been developped so far inside the Geronimo > TLP, part of the reason is that some of the people working on it were not > felix committers, so it was way easier to work there instead of contributing > patches until getting committership. It is very difficult to commit to > work on a new implementation of anything when you don't even have commit > priviledges. It's ok for patches, but not for a new dev. That's what we > have here. We have people here wanting to work on some new OSGi spec > implementation, and the only way for them to do so at Apache in to go into > the incubator. > > Even, if Aries was to compete against Felix in any way, it's not a good > enough argument. We already have multiple projects in the ASF that do have > overlap as it was pointed already multiple times in this thread: mutliple > REST implementations, multiple JAX-WS implementations, etc... But the Aries > podling does not aim to even provide alternative implementation to what > Felix already has, it's goal is to create a community with new people who > want to work on that and deliver both implementations of new OSGi specs > (such as blueprint and subsystems / applications, jpa ...) and also > additional extensions (such as blueprint custom namespaces for transactions, > etc...). > > For the independance, the only real place I know which provides OSGi > components, not tainted with a given framework are SpringSource (though it's > open source, the community is not really open) and OPS4J, but I do think > it's a different discussion. > > I restate that the goal of the Aries proposal is to foster a community > around some new code implementing some OSGi specs. And I don't think we can > do that inside an existing TLP, as we have non apache committers that want > to create this code. That's what the incubator has been created for. > > Last, accepting to create a podling does not mean the final destination of > the podling is defined yet. Aries could become either a TLP, a Felix > subproject, or be split across the two of them. The one that makes the most > sense should prevail at graduation time. By the time Aries is ready to > graduate, the discussion about it's final destination will be held. And > that's where what you say will make sense and where your vote needs to be > cast. > > I really do understand your concerns (even if I don't share them), but now > is not the time to vote -1. > > On Wed, Sep 2, 2009 at 16:30, Richard S. Hall <he...@ungoverned.org> wrote: > >> I will try to keep this short. >> >> The OSGi Service Platform is composed of the core and compendium specs. The >> EEG specs are not in any way special and will ultimately end up as part of >> the compendium spec. Apache Felix was incubated to build a community at >> Apache around implementing the OSGi specs. >> >> Now we are being told that this mission is too tainted because we implement >> the framework spec, which is part of the core spec. I find this unfathomable >> given the nature of OSGi and the efforts to which the Felix community goes >> to be good OSGi citizens...we even allow for competing implementations >> within our community. >> >> It is also particularly odd, since the Equinox and Knopflerfish communities >> are in the same situation, implementing both core and compendium specs with >> their frameworks largely synonymous with their project name. >> >> I am not naive enough to expect this discussion to change much, since I >> imagine there has already been a fair amount of political calculation around >> this proposal, otherwise the Felix community in general would have been >> engaged earlier. >> >> So, here's my vote: >> >> * -1 for the portion of the proposal creating yet another community >> for implementing OSGi specs at Apache since the Felix community >> would happily welcome more contribution (just like recently >> occurred with ServiceMix members being accepted as Felix >> committers and PMC members for the Karaf subproject) >> * +1 for the rest of the proposal to explore how to build an >> enterprise component model on OSGi and the other non-spec related >> topics. >> >> -> richard >> >> >> >> On 9/1/09 22:53, Kevan Miller wrote: >> >>> >>> On Sep 1, 2009, at 2:08 PM, Richard S. Hall wrote: >>> >>> On 9/1/09 13:59, Martin Cooper wrote: >>>> >>>>> On Tue, Sep 1, 2009 at 10:51 AM, Richard S. Hall<he...@ungoverned.org> >>>>> wrote: >>>>> >>>>> I'm not sure I understand the issue here. Whether Aries becomes its >>>>> own TLP, or a sub-project of Felix or some other TLP, isn't relevant >>>>> until the project is ready to exit incubation. Why does it warrant >>>>> such apparently intense discussion before the project is even accepted >>>>> >>>>> >>>> We are actually discussing something else. We are discussing the scope of >>>> the proposal, which includes hosting OSGi standard service implementations, >>>> which is part of Felix' scope. >>>> >>>> If we are developing standard OSGi services within Apache, then Felix >>>> provides an enthusiastic community to do this and there is no need to start >>>> another incubator project for such a purpose. On the other hand, stuff like >>>> "a set of pluggable Java components enabling an enterprise OSGi application >>>> programming model" makes perfect sense to be incubated. >>>> >>> >>> Thanks for the clarification... So, your issue is mainly with "It is a >>> goal of the Aries project to provide a natural home for open source >>> implementations of current and future OSGi EEG specifications..."? >>> Personally, I tend to think of Felix in terms of OSGi Core Platform. I >>> certainly hadn't expected it to be the source for all OSGi standard >>> implementations from Apache -- not for implementations of Enterprise Expert >>> Group specs, anyway. I'm sure there are flaws with my perceptions... >>> >>> So, we have a group that is interested in working on an enterprise OSGi >>> application programming model at Apache (including implementations of at >>> least some EEG specifications). An incubator project would seem to be an >>> excellent place for this work to start. Interested Felix community members >>> would certainly be able to join this effort. >>> >>> It then becomes a question of, assuming successful incubation, where does >>> the community graduate to? TLP, Felix subproject(s), or elsewhere. All >>> successful outcomes, IMO. >>> >>> --kevan >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Karl Pauls karlpa...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
