No there we have Ted and Craig saying something differently - now who of the two experts is right?
is it possible to develop something on Sourceforge (by non-commiters) and have it checked in to the ASF codebase by an ASF committer without going through the incubator? Craig says yes - the committer has to take responsibility for sorting out the legal issues and everything Ted says no - everything has to go through incubator. May I suggest that it depends on the size and the clarity of the legal situation of the contribution with respect to the existing codebase - one component of one developer who puts the component into public domain might be okay, several would need to go through incubator? regards, Martin On 5/15/05, Ted Husted <[EMAIL PROTECTED]> wrote: > 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. >
