Am 20.02.2013 14:26, schrieb Raul Kripalani:
I'm thinking about the organisation strategy here. Below is a list of a few
practical issues off the top of my head. For the people supporting the the
marketplace idea, could you elaborate on how we'd handle these?
- Would marketplace components be sponsored/owned by committers only, or
anyone is free to contribute?
Anyone should be able to contribute. Perhaps an ICLA should be necessay.
- What's the screening process when a new component is submitted? Or is
there any?
I would limit the screening to legal issues. So mainly licensing.
- What if a component is abandoned by its sponsor in the marketplace?
Then it would not be released anymore. The PMC might be able to select a
new owner.
- How do we supervise the quality of components? The quality of
components since day 1 has been a big success factor of Camel so far.
The quality would be in the responsibility of the owner.
- Will the committer team stand responsible if a component simply
doesn't work as advertised?
No
- How would issues and tickets be tracked? In the ASF JIRA?
To use jira makes sense. Perhaps in a new project.
- How would we align, organise, coordinate Camel releases with N
component sponsors? Until now, the voice of community has been -1 to
independent component versioning. So even if we open a Camel Marketplace,
component versions would need to stay aligned.
Basically not at all. The releases would not be coordinated centrally.
If a component becomes incompatible with a new version the owner would
have to do the changes and publish a new release.
- Where would documentation be hosted?
I propose to keep the documentation in confluence. Perhaps in a separete
project.
The number of components increasing to a level beyond our capacity is an
undeniable sign that the Camel community is thriving. We should be thinking
of expanding the Committer Team rather than outsourcing work to other
communities and other approaches ;)
A larger team is more difficult to coordinate. The marketplace aproach
should be able to scale better.
Of course an important factor is that the API does not change too much
over time. So ideally components stay compatible with a big range of
camel releases.
This requires a lean and well designed API which we are currently
lacking. But perhaps we can provide this in the camel 3 release.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
