incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <>
Subject Re: [DISCUSS] Do we really need an incubator?
Date Tue, 08 Jul 2008 10:25:37 GMT

- We have 11 failures so far in the incubator
- We have had G PMC pick up the code from a failed incubation (Yoko)
- We have disclaimers all over the place

Any PMC that ships incubator developed code is responsible for what
happens when a community does not form around the code base used. Any
one outside Apache that ships incubator code should be totally aware
of what they are getting into. Example we used yesterday on IRC was if
Mule ships Abdera. Mule is taking ownership of the risk of abdera
failure. Same as was the case with G PMC and Yoko. This is not about
whether we are legally clear w.r.t the releases.

Bottom line, who ever used abdera code should do it consciously. I
agree that adding a second repo may be causing pain to the end users.
But this is for better or worse a "feature" because we don't have a
better way of doing this given the tools we have and the use cases the
tools are pushing on unsuspecting users :)

So can we figure out another way to make the end user make a conscious

I doubt we will get much help from the maven team to support this use
case. They would rather get the central repo and get it done! What
bugs me is that in this whole discussion, no one even mentions how
easy it is to add another repo in the poms or the settings.

Why can't people at least pretend to come up with some alternatives
rather than just chant "central repo!" :)


On Tue, Jul 8, 2008 at 1:51 AM, Bertrand Delacretaz
<> wrote:
> Hi Dims,
> On Mon, Jul 7, 2008 at 11:09 PM, Davanum Srinivas <> wrote:
>> Sorry...Need to take this off my chest before the official VOTE.
> Thanks for this.
>> ...Looking at the maven repo thread, begs the question. Do we really need
>> an incubator?
>> Isn't it just a IP Clearance SVN now once people have their way with
>> no distinction at all between incubator and non-incubator code?...
> It took me a few seconds to understand your concern, I had never
> thought about it like that before.
> I don't think putting incubator artifacts in the main Maven repository
> removes all distinction between incubator and non-incubator code. If
> we require incubator artifacts to have "-incubating" in their version
> names, that's perfectly clear.
> Such a dependency might be made somewhat invisible by transitive
> dependencies on incubating projects, but the problem is exactly the
> same if a non-incubating project depends on GPL stuff transitively.
> That's a Maven problem, not an incubator problem.
> Currently, one has to explicitely check their complete dependency tree
> to sure about what their code uses, when working with Maven. Or use
> private repositories exclusively, with controlled addition of
> artifacts. That's not in any way an incubator problem.
> To answer your question, to me the value of the incubator is as much
> in creating communities as in creating clean code. Having been a
> mentor of Wicket, I think this is a perfect example of a community
> that already worked quite well, but needed some mentoring to ease into
> the Apache way, and I think the results were very successful.
> Other projects don't incubate as well, especially now that the
> incubator has grown larger with relatively few people (IMHO) taking
> care of the health of the incubator at large.
> To me this means that a few things need to be fixed in the incubator -
> like reducing bureaucracy to a minimum while avoiding losing track of
> incubating projects, making docs more consistent and minimalistic, and
> making sure companies do not hijack their way into the ASF via the
> incubator.
> That doesn't mean we don't need an incubator, quite the contrary in my
> opinion: we need a stronger and more fun incubator.
> -Bertrand
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Davanum Srinivas ::

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

View raw message