Richard,
#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 d...@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.
thanks,
dims
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 d...@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 etc..is 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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
