incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <>
Subject Re: Incubation Questions
Date Tue, 21 Apr 2009 19:52:05 GMT
Hi Scott,

Scott Merrill schrieb:
> Hello everyone.
> I am a participant with a project that is discussing applying for
> incubation. We've been around for several years, and have a
> non-trivial amount of established infrastructure, including wiki, bug
> tracker, and mailing lists. We have a number of questions related to
> these services insofar as successful incubation would be concerned.
> Our wiki is open to anyone who wants to make an account. The wiki is
> the primary point of collaboration for the end-user manual we
> distribute with our project. The Incubation guidelines state
>    "In particular, care must be taken to ensure that access to the wiki used to
>    create documentation is restricted to only those with filed CLAs. The PPMC
>    MUST review all changes and ensure that trust is not abused."
> We're not totally keen on that restriction, though we understand the
> intent. One possible work around would be two wikis: a public wiki
> open for participation by any interested party, and a "restricted"
> wiki for "officially sanctioned contributions". A member of the
> project could cull contributions from the public wiki and move them to
> the restricted wiki. This begs the question, though: would such a
> public wiki be permissible within the Incubation-provided
> infrastructure?

Yes, in Apache Sling we do exactly this. We have a SLINGxSITE space
which is the basis for the official site and which is access protected
and we have the SLING space, which is open but is not the "official"
documentation of Sling -- though, of course, we pay close attention, too.

> Are we permitted to maintain our own wiki, on our current
> infrastructure, during the incubation process?
> Are we permitted to maintain our own bug tracker, on our current
> infrastructure, during the incubation process?
> I realize that both of the above fly in the face of some of the point
> of incubation, but we'd like to make sure we're exploring all the
> possible options before we lock into potentially major changes.

Hmm, others must reply to this one. But I think at least during the
lifetime in incubation the migration into the ASF infrastructure should
be accomplished.

Maybe someone from Wicket which also had a community before its Apache
life could answer here and provide some experience.

> We currently use Launchpad ( to facilitate
> end-user contributions to our translation efforts. Would it be
> permissible to keep using Launchpad? Would people contributing
> translations be required to sign a CLA? Note that we currently do not
> distribute translations with the releases. We don't have a clear sense
> yet on whether want to change this practice.
> The Incubation documentation states that "incubator projects are not
> permitted to issue an official Release. Test snapshots (however good
> the quality) and Release plans are OK." Is that just a semantic issue?
> We haven't yet released a version 1.0 of our project: could we simply
> label our next intended release (currently 0.7) as a "test snapshot"
> and carry on as normal?

True to some extent. Incubator project releases are not fully sanctioned
releases, though they go through the same procedure checking for
compliance with ASF rules. As an indication of this fact, all releases
of incubating projects may have the word "incubator" (or "incubating"
IIRC) in its version.

To be honest, though, to most downstream users, the difference between
an incubator release and a real ASF release is kind of subtle.

For example in Apache Sling (which I know best since I am a member of
this incubating project) we have a Release 3-incubator. This is fully
functional but the "incubator" tag marks this as a release of a project
in the Incubator.


> Thank you very much in advance for any insight you can share.
> Cheers,
> Scott
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message