Niall Pemberton wrote: > On 3/9/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote: >> >> Matt Benson wrote: >> > --- Niall Pemberton <[EMAIL PROTECTED]> wrote: >> > [SNIP] >> >> I didn't know whether this had been done before in >> >> Commons - but seems >> >> that it has for the Commons CSV component back in >> >> December 2005: >> >> >> >> >> > http://incubator.apache.org/ip-clearance/jakarta-commons-csv.html >> > >> > Actually I knew about this but thought I remembered >> > someone (Henri?) saying later that having gotten the >> > code in this way might not have been the best choice >> > in retrospect. Does that ring any bells with anyone? >> >> Yep that rings a bell and going down that route again, is not >> something that has my support for >> *new* components (which this is). If the code is destined for an >> existing codebase, we could do the >> IP route, else I would like to see some level of incubation (besides >> handling ip). See the >> discussion on not-yet-commons ssl. > > I'm wondering why? Seems to me that this is a slightly different > situation to either CSV or the SSL situations since one of the > developers is an existing ASF and Commons committer.
There are new committers involved. With CSV Henri is a committer (not talking karma here) (and me too, although we are both not very active). I think when new people are involved incubation (besides legal) should occur (even though the community import isn't that big, compared to similar situation like activemq, servicemix, etc, where the core developers are actually ASF Members) In case of this scenario (and ssl) I "envision" this for incubation : - Get the people on board as a committer on the initial proposal - Have them *show* that they are here to stay for an x amount of time - Ideally have the normal exit criteria, although I can imagine for commons a slightly weaker exit strategy may be adapted (don't think the incubator thinks that eg 3 committers on a project is a vibrant community, although within commons it definitely will be!). - Get a release out. If someone starts hacking on code in the sandbox I am ok with that, but rather not see new code again hitting the sandbox, since we "don't" accept new committers on sandbox components and it doesn't have the ability to have a release (disclaimer : I became committer in Jakarta because of a sandbox component, ahum). I highly prefer that incubating commons components to use the commons-dev and commons-user list, since to do development however, since it would be quite a cultural shock when moving from incubator specific lists to the commons ones. Disclaimer : this is just a brain dump and I would love to see some new projects at Jakarta, but I think we also need to figure out how we should handle that in a constructive way and prevent feedparser and csv situations. Mvgr, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
