Well, if the dependencies never graduate, it's easy to copy the code into your own project since it is Apache licensed.
> +1 - good idea to start on Wiki and then move web once stable. I > think Simon's summary is excellent, but I have one caveat that I would > throw in under > > * Easy for other apache projects to depend on it. > > Apache projects should be careful about depending on things in the > commons sandbox. Experimenting with the idea of eventual dependency > (e.g. [chain]), or factoring out code "experimentally" (e.g. > [resources]) is fine, IMHO, but creating hard dependencies while > things are still in the sandbox is not a good idea, as there is no > guarantee that things in the sandbox will ever see an official > release. > > Phil > > On 3/8/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: >> 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 >> onset. >> >> 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? >> >> -Rahul >> >> >> On 3/8/06, Simon Kitching <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > James Carman, President Carman Consulting, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
