Guillaume Nodet 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.
Having apache committers from a project be granted commit access to
another project is not really a problem, as soon as the other project's
PMC decide what are the "rules".
The new project can also be a Felix subproject, with specific commit
access granted to a specific set of committers, if needed. I'm pretty
sure that infra can deal with such a granularity. Also the felix PMC can
check that the new committers are not committing in the other projects,
if needed.
So far, this is how we did for FtpServer, SSHd and Vysper in MINA. In
fact, Vysper is still in a sandbox, but I can see the moment where it
will get out, either as a MINA subproject, or as a TLP. The biggest
advantage is that, as all the committers were already working on other
projects, and as the MINA PMC was able to check that the project was
following the rules (IP, etc), it's far easier than going through
incubation.
I can see how better it could be for Aries to start as a felix
subproject, for many reasons.
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...).
It would be better to see Felix as a OSGi aggregator (a bit like WS or
DB are), with potentially many implementations. It would be so great if
Buildr, Ant, Maven, Archiva, Continuum, were all embedded in a Build
Tools project, instead of being one of the 70 TLP. From the user PoV,
it's difficult to know what they all are doing.
This is a bit more general than just Felix, here. We have more than 70
TLP, and this number will continue to grow in the next few years. Why
can't we aggregate projects within categories at some point ?
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.
I'm not sure that because a project has non apache committers, it should
be started in incubator, as soon as the TLP can "educate" the project.
of course, if all the peope are non apache committers, that's a
different story.
That being said, the best would be to first check for synergies, then
think about creating the poddling if there are not too much overlap. Be
pragmatic !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
