Hi. I think that Matt have well explained needs for Commons Incubator . In addition to that, this is a short story from my experience. One month ago, I introduced my component called as Robust-Task through Commons mailing and Incubator mailing. There were some opinions for my component and I thought my component may be suitable for Commons because it is relatively small and similar to Commons Chain. So, I wanted that my component is incubated by Commons. However, I saw a point that I don`t commit anymore if I send my component to Commons Sandbox which seems to be used as incubator in Commons. I thought that this is not reasonable. This was a difficult problem to me.
With this experience, now I also see a need for Commons Incubator. In my opinion, Commons Incubator aims at resolving a new problem, not an overlapped problem. On Fri, Apr 10, 2009 at 11:56 PM, Matt Benson <gudnabr...@yahoo.com> wrote: > > > > --- On Fri, 4/10/09, Torsten Curdt <tcu...@apache.org> wrote: > > > From: Torsten Curdt <tcu...@apache.org> > > Subject: Re: [PROPOSAL] Commons Incubator > > To: general@incubator.apache.org > > Date: Friday, April 10, 2009, 5:32 AM > > Well, the point is: we are > > talking about small libraries. > > > > Imagine there is library X which was developed by only 2 > > developers. > > They want to bring this code to Commons. What to do? IP > > clearance is > > one thing. But what about the 2 developers? Just make them > > committers > > while they have no clue about Apache? Doesn't sound like a > > good idea. > > Just accepting their code and make them send patches until > > we feel > > they are ready? Feels not appropriate since they are the > > authors of > > the code. On the other hand going through the "normal" > > incubator is a > > bit over the top for a project that is so small that it is > > not > > targeting to become it's own project. Building a community > > is not > > really that applicable in this case. It's rather about > > integrating it > > into an existing community. > > > > Thanks Torsten--I think you've pointed out the proverbial Scylla and > Charybdis here: > > * IP clearance means reducing the original authors of codebase X to > contributor status. It could be argued that this is a way of teaching them > that within the context of the ASF, the direction of "their" code will be > determined by the community. More likely, however, they will simply opt to > take their ball and go home. Surely there are better ways to teach the > "Apache way." > > * "full" Incubation sets a small component up for failure to graduate due > to not gaining a community large or diverse enough to satisfy Incubator > graduation requirements, when, were the same code to begin life in the > Commons sandbox, originated by ANY existing ASF committer, it would be > subject to somewhat less stringent graduation (to Commons "proper") > requirements. > > The other problem with full incubation, inordinate effort to set up _n_ > relatively tiny podlings, really affects infrastructure more than it affects > Commons. > > The current state of affairs makes it highly impractical for any codebase > that includes IP from a non-ASF-committer to enter Apache Commons. What we > are asking for could be alternately seen as the Incubator's blessing to > establish a "decontamination chamber" much like our sandbox but where > community members can commit prior to their component being accepted into > Commons "proper" and their consequentially becoming "true" ASF committers. > Note that some of my wording reflects a perception on my part that there is > a difference between a podling committer and a committer to some TLP (or TLP > subproject). If that is not the case, I'd be interested to know that, but I > don't believe it affects the overall argument here either way. We need an > officially sanctioned concept for "Commons podling committer." > > [SNIP] > > > On Fri, Apr 10, 2009 at 11:59 AM, Justin Erenkrantz > > > <jus...@erenkrantz.com> > > wrote: > [SNIP] > > >> > > >> -1 (vote, not veto). > > Finally, I'm apparently not familiar enough with incubator procedures to > understand "when a -1 is not a veto." Can anyone provide any more info on > that? :) > > Regards, > Matt > > [SNIP] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Min Cha, Dreaming Developer Task Framework : http://code.google.com/p/robust-coupe/wiki/RobustTaskIntroduction English : http://minslovey.blogspot.com Korean : http://minslovey.tistory.com
