On 5/11/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > Would this satisfy the ASF's requirement for "All New Components Must Go > > Through the Incubator" ? Hopefully... > > I think Ted's concern regarding this (from the myfaces-pmc thread) is > that code that is *already developed* outside of ASF should not go > straight into the project. So for components that grow out of > discussions on this board would not apply. Hopefully that is what he > meant anyways.
It's more like all external "codebases" donated to the Foundation *must* go through the Incubator. The two concerns are IP and Community. First, the ASF wants to be positive that we do in fact own every line of code in our repositories. Of course, under the Apache License, we don't mean "own" in the exclusive sense. But "own" in the sense that we can put it under the Apache License, and no one else has a legal right to complain. If an external codebase could enter the ASF through any of our dozens of projects, it would be too easy for a project to slip and allow in a codebase with IP issues. So, when IBM donates Derby, it doesn't go straight to db.apache.org, it goes to the Incubator first, where another set of eyes can look it over. Now if the codebase is developed here in our repository, regardless of its size, then we own it and we can put it under the Apache License. It's only external codebases developed by non-committers that concern Incubator. Of course, the ASF doesn't want code as much as we want community (people who create, maintain, and support code). Before any large donation is accepted, we need to know that there are *several* members of our community who will support the code over the long term. Essentially, the Incubator is a front controller for new projects and external code donations. A lot of projects maintain sandboxes to ensure that there is a community support behind a codebase before making it part of the trunk. Once it is part of the trunk, there is an expectation that *all* of the committers are ready, willing, and able to support the code over the long term. Another word for sandbox is "whiteboard directory", as mention in the Rules for Revolutionaries. * http://incubator.apache.org/learn/rules-for-revolutionaries.html If you have a sandbox, or whiteboard, then it should be very, very clear to anyone using the component that this code is not part of the main distribution, *and* that it subject to change or removal without notice. If its too easy to use the sandbox code, then people might not realize that it's not part of the standard distribution. Of course, under SVN, it is quite easy to merge and move components later, no matter where you hide them now :) Often, people will develop novel or "revolutionary" code in the sandbox, then propose that it be promoted when the code is ready for primetime. (Where primetime means the code is stable and there are several people interested in using and supporting the code.) But, "evolutionary" code can be developed as part of the trunk, if everyone agrees its something that needs to be part of the next release. Generally, a sandbox is for questionable components that may or may not be made part of the standard release. This is important, because Apache Projects are expected to fully support whatever goes into a standard release. If it goes into the standard release, it should be bug-free in every subsequent release, and if it we decide to remove it, we should go through a deprecate-replace-remove cycle over two or more stable releases. Putting code in a standard release means we are committed to the code. Putting code in a sandbox is "throwing stuff on the wall and seeing if it sticks" :) Whether a component *needs* to go through a sandbox would depend on whether it *needs* to be part of the next standard release. If it's in the trunk, and it's not done yet, then it becomes a blocker until it's done (or moved out of the trunk). On 5/11/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > What about the sourceforge project that has already been set up? As mentioned, some people on the Struts team setup a SourceForge site to make it easier for non-committers to share code with the Struts community. But it is not used as an actual sandbox. (Struts already has one of those.) It's just a place where people can share Struts extensions and sample applications outside of the standard release. Of course, if a non-committer wants to develop something and then propose it to the Apache Struts Project, a good approach would be to develop it on the SourceForge site. But, it would still have to go through the incubator and all that. When a Struts committer want to develop something that might become part of the Struts release or a new Struts subproject, we start it in the ASF repository, not the SourceForge site. The cool thing about a sandbox, as used by Struts and Jakarta Commons, is that you don't need group approval. You can start it up, and see how it goes, without having to convince anyone first. It gives you a chance to do the code, and then let the code do the talking. HTH, Ted.
