On Sun, 2006-04-09 at 19:19 -0400, Noel J. Bergman wrote:
> Andrew C. Oliver wrote:
> > Then there is no NEED for a sandbox.
> As you know, the sandbox predates the Incubator, and AIUI, the Sandbox
> exists so as to allow experiments without polluting the respository in such
> manner that would confuse the public and ourselves about what is real and
> what is play.  There may be other ways in to achieve that goal.

Agreed. I think much of the Sandbox concept owes its existence to the
limitations of CVS, and that with Subversion and the recent jakarta-wide
commit access a lot of the need for a sandbox is gone.

A project which has ties to an existing one (eg a refactoring of common
code out of a project into a "common component") can be done in a
sandbox subdir of that project (sibling to trunk/tags/branches).
Discussion can be held on that project's lists. Oversight is provided by
the committers on that related project. When it's ready to be promoted,
a simple "svn mv" and the creation of a separate email list will do the

For projects which are brand new but likely to become part of jakarta
commons, the existing commons sandbox (using the existing commons-dev
list) seems appropriate to me. Oversight is provided by the commons
community. Of course if the project is a kind of "language extension"
then it might want to hang out on the proposed commons-lang-components
list instead of the original commons list.

Projects that originate outside apache and are being brought in go
through the incubator of course. Oversight is provided by those kind
apache committers who subscribe to the incubator lists.

The only problem I see is largish projects that are originated by
existing Apache committers and have no close affiliation to existing
projects. There aren't likely to be very many of these. I would suggest
that if such a project can't find an existing project willing to
effectively "sponsor" it by allowing their own list and subversion dir
to be used to host the project for a while, then it belongs in

The other issue to consider is where websites for sandbox-status
projects can live. I think it would be nice to group these together, eg
under jakarta.apache.org/sandbox. This provides a way for such projects
to publish sites while making it clear to users that they aren't yet

To summarise: I suggest setting up a parent website for jakarta-wide
sandbox stuff, and dropping the existing sandbox docs that encourage
non-commons projects to come and play in the commons sandbox. Otherwise
things can be pretty much left as they are...



To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to