On Mar 1, 2013 8:33 PM, "Niall Pemberton" <niall.pember...@gmail.com> wrote: > > On Tue, Feb 26, 2013 at 9:52 PM, Greg Stein <gst...@gmail.com> wrote: > > I concur with Chris, and want to strengthen/meta the point. The Incubator > > should not be used for projects which are intended to become part of an > > existing TLP. The Incubator *creates* Apache-style communities. But... Stop. > > > > For these, we don't want a separate/new community. They are supposed to be > > *part of* the existing TLP. Thus, they have no business here. They should > > start within the target TLP. > > The incubation of WebWork into Struts is an example where there was an > existing project outside the ASF with an existing bunch of developers > that were not ASF committers. The point of going through the incubator > was for the communities to merge. I guess at the time we could have > just given comitt access to all WebWork devs - but most of us on the > Struts project didn't know them. Is that what you're proposing should > happen in this scenario?
Yup. The Incubator doesn't have "staff". It really doesn't make sense to put a community in their hands. Either a community self-builds, or it should become part of an existing community. For the WebWorks case, I would rather have seen them get a branch in Struts. Over time, the features would get integrated from the branch to trunk, and the committers would get expanded commit access. I understand a project may arrive, thinking to become a TLP, but later change their desired exit. But I think it would be best to call that an exception. Instead, we let target communities directly teach the incomers about operating within their (our ASF-style) community. Cheers, -g
