incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Date Sat, 05 Sep 2009 10:39:48 GMT

#2 - "Finished impls could quickly be released as non-incubator artifacts." is also something
that i am not comfortable 
with, at least until the new committers get off the ground, attract a user community and show
that they are able to 
follow the ASF way.

Ideally my hope is that dev@felix folks should guide the community being formed within the
incubation podling process. 
If we can get anyone interested join in as a mentor and/or committer that would be wonderful.


On 09/04/2009 06:04 PM, Richard S. Hall wrote:
> On 9/4/09 16:49, Davanum Srinivas wrote:
>> Richard,
>> I see your viewpoint better now. Thanks.
>> One more question, Will there be a problem of folks on dev@felix not
>> being able or willing to participate in a new podling? (If the folks
>> presenting this proposal do wish to start off as a podling)
> Dims, since I don't speak for all Felix community members, I can't
> really answer that question. I imagine that interested parties would
> contribute, but certainly a benefit of at least doing any independent
> OSGi spec impls at Felix is you will automatically get the oversight of
> people who have been doing it for years, if not their contribution. The
> separation could possibly make life simpler too for those willing to
> help, since:
> 1. People interested only in the OSGi spec impls do not necessarily
> have to be involved on Aries mailing lists that will likely
> incorporate a lot of discussion about the Aries component model
> and related content.
> 2. Finished impls could quickly be released as non-incubator artifacts.
> -> richard
>> thanks,
>> dims
>> On 09/04/2009 04:31 PM, Richard S. Hall wrote:
>>> On 9/4/09 16:10, Davanum Srinivas wrote:
>>>> Richard,
>>>> On 09/04/2009 03:49 PM, Richard S. Hall wrote:
>>>>> So, no, I am not saying "everything should", but in general, it
>>>>> would be
>>>>> nice if the spec impls started there since we have a community of OSGi
>>>>> users and OSGi experts who are very active and receptive, many of whom
>>>>> also work in the EE space.
>>>> Will the people mentioned not participate if Aries is a separate
>>>> podling to start with? After all destination PMC can be determined
>>>> during graduation process. Also the incubation process is to show new
>>>> incoming team how Apache works that better done as a podling
>>>> or as a felix sub project? If we continue the same thought process,
>>>> will there every be any incubator podling with for any OSGi related
>>>> activity?
>>> Yes, and I mentioned this, but that seems to get lost somehow.
>>>>> In short, it makes sense for spec impls tied to the Aries component
>>>>> model (for example), to be hosted there, but there is little need to
>>>>> create another project to incubate generic OSGi spec impls, since the
>>>>> Felix community was set up for that. The reality is, most OSGi
>>>>> specs are
>>>>> not huge projects so we likely wouldn't want TLPs for all of them, but
>>>>> nothing stops a subproject started at Felix from going TLP if it takes
>>>>> on a life of its own.
>>>> Choices are
>>>> 1) Podling -> TLP
>>>> 2) Podling -> Felix Sub project
>>>> 3) Podling -> Felix Sub project -> TLP
>>>> 4) Felix Sub project
>>>> 5) Felix Sub project -> TLP
>>>> The first 3 effectively uses incubator process(es) to educate the
>>>> incoming folks and provides a strong grounding in ASF-land (at least
>>>> that is what the intention is :)
>>>> So, why should we bypass incubator?
>>> Again, there was already a project incubated to educate incoming folks
>>> on how to create open source OSGi spec impls at Apache, so why do we
>>> need to repeat that process?
>>> Your phrasing of this question implies we are trying to somehow skirt
>>> the Apache way, but educating incoming people via contributions and
>>> meritocracy to an existing project is not some shortcut.
>>> -> richard
>>>> thanks,
>>>> dims
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message