commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject [sandbox][all] New sandbox projects (was Re: Commons Metadata?)
Date Wed, 08 Mar 2006 22:56:06 GMT
I think in one of these recent threads, there was talk about coming up
with a document that we can point to whenever a new sandbox project is
formed / proposed, so Simon doesn't have to type his email each time
;-) (see bottom of this email).

A document that aims to strike a balance between:

 * The sandbox is truly open to any Apache committer, and there is no
need to ask for permission (other than posting a formal [PROPOSAL]
email whose outline exists on the website). Who is to say whether or
not it will "take off". We need to be welcoming.

 * The mechanics of sandbox graduation and releasing, requiring
support from enough Jakarta PMC members and so on. Based on recent
history, we need to be cautious, and maybe point this out at the

Ofcourse, this may change if and when the Jakarta sandbox is formed,
interim should be post such a "things to consider" document? On the
wiki, on the website?


On 3/8/06, Simon Kitching <> wrote:
> On Wed, 2006-03-08 at 12:46 -0500, James Carman wrote:
> > If I write it, I can have the Trails project use it probably (I'm a
> > committer).  Do we just have to have clients who are interested in the
> > project or do we also need more than one developer to work on it?
> The sandbox is open to anyone; you can just get stuck in. However you
> have to consider whether it is more *productive* to host your project
> elsewhere (eg sourceforge).
> Benefits of sandbox:
> * Existing commons developers are watching.
> If you think this project would be of interest to a number of existing
> commons developers then it's beneficial to use sandbox as it will make
> them aware of the project
> * Easy for other apache projects to depend on it.
> Apache projects are generally happier depending on apache-hosted
> projects than external projects (though that's not an absolute rule).
> In particular, for code factored out of an existing apache project
> it makes sense to use sandbox.
> * Easy promotion to proper
> When the project has been developed in the sandbox, it's simply a vote
> to move it to proper. When developed externally, contributor agreements
> etc are probably needed before moving the project *to* apache.
> Disadvantages of sandbox:
> * It's very difficult getting non-apache developers committership.
> If Sue Smith notices the project and wants to get involved she basically
> can't. Only apache committers can have sandbox access, and apache
> committership is not something granted lightly. In sourceforge, of
> course, the project administrator just adds any user they want.
> * Very low visibility
> People can find sourceforge projects much easier than they can find
> sandbox projects.
> * Releases
> You can't make official releases of a sandbox project before it's
> promoted to proper. And it cannot be promoted to proper unless you can
> attract at least a couple of other commons committers to work on the
> project. This needs very serious thought; if you're not going to get
> that support in commons then sandbox is a permanent dead end.
> Cheers,
> Simon

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

View raw message