I am attaching an email trace by Noel and Cliff from a question I asked at the incubator mailing list, which basically said that we don't have to do an incubator subproject for anything which we think we can maintain - so Craig seems to be right in this issue if number of opinions count ;)
regards, Martin On 5/14/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Cliff Schmidt wrote: > > > you'd only need an incubator subproject if the code could not be > > supported by the current MyFaces community. However, if the > > MyFaces PMC feels that the community already exists to maintain > > the new code contribution, then there's no need for an incubator > > subproject. > > But the IP must still be vetted and recorded (q.v., > https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/projects > /ip-clearance-template.html). > > --- Noel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > On 5/15/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > 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. > > >
