On 3/9/07, Matt Benson <[EMAIL PROTECTED]> wrote:
Apologies for the top post. This puts us back to square one, with noone, at least from Jakarta, apparently interested in being champion, rendering the whole discussion moot. ;) Is there an appropriate next step other than simply forgetting about incubating?
No need to forget it if you don't find a champion soon. Patience and continued development of the project and the community around it can pay off. More interest may come in time. For instance, i've no time to take up the cause of a project that i'm not using at work, but you've piqued my curiousity about the project. When next i need conversion support such as it provides, i'll be sure to investigate Morph more deeply as an alternative to just BeanUtils. Then, schedule permitting, i might be willing to help with incubation, as it would be more in my interest. I wouldn't be surprised if others are thinking much as i am here.
-Matt --- Niall Pemberton <[EMAIL PROTECTED]> wrote: > On 3/9/07, Martin van den Bemt <[EMAIL PROTECTED]> > wrote: > > > > 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. > > OK, good explanation - sounds reasonable to me. > You're right going the > incubator route would bring Matt Sgarlata in with > the code which would > be more desirable. > > Niall > > > Mvgr, > > Martin > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ____________________________________________________________________________________ Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
