Hi Nigel, I liked your previous plan. Could you summarize your current plan?
Are we now planning to leave inactive projects in place? Ship them as source? Seems like this still sends a confusing message. I'm all for removing them from trunk in SVN, leaving a wiki link to their most recent state and letting their contributors make a case to revive them in whatever place they choose. Keeping projects with small constituencies in our tree seems counter productive. E14 On Feb 11, 2011, at 10:01 PM, Nigel Daley wrote: > +1. And only include them as source in releases. > > Nige > > On Feb 11, 2011, at 10:12 AM, Tom White wrote: > >> For contrib components that we elect not to remove, I suggest that we >> remove them from the main build, so that failures in a contrib >> component don't hinder the main build and release. This is what >> ZooKeeper does, for example. >> >> Tom >> >> On Fri, Feb 11, 2011 at 2:03 AM, Bernd Fondermann >> <[email protected]> wrote: >>> -1. >>> >>> Move it away from TRUNK so it doesn't affect builds is a much better >>> (and simpler) solution. If someone wants to revive it, he can within >>> the bounds of Apache Hadoop and will become a part of the Hadoop >>> community, which would be good. >>> If you'd move it off-site, if the code ever gets new contributors, >>> it's hard to integrate them (code and contributors) into Hadoop again. >>> >>> AFAIUI, apache-extras is for placing non-Apache code closer to the >>> related Apache projects, not for moving our code away from our own >>> premises. >>> >>> Bernd >>> >>> On Mon, Jan 31, 2011 at 04:42, Nigel Daley <[email protected]> wrote: >>>> Folks, >>>> >>>> Now that http://apache-extras.org is launched >>>> (https://blogs.apache.org/foundation/entry/the_apache_software_foundation_launches) >>>> I'd like to start a discussion on moving contrib components out of >>>> common, mapreduce, and hdfs. >>>> >>>> These contrib components complicate the builds, cause test failures that >>>> nobody seems to care about, have releases that are tied to Hadoop's long >>>> release cycles, etc. Most folks I've talked with agree that these contrib >>>> components would be better served by being pulled out of Hadoop and hosted >>>> elsewhere. The new apache-extras code hosting site seems like a natural >>>> *default* location for migrating these contrib projects. Perhaps some >>>> should graduate from contrib to src (ie from contrib to core of the >>>> project they're included in). If folks agree, we'll need to come up with >>>> a mapping of contrib component to it's final destination and file a jira. >>>> >>>> Here are the contrib components by project (hopefully I didn't miss any). >>>> >>>> Common Contrib: >>>> failmon >>>> hod >>>> test >>>> >>>> >>>> MapReduce Contrib: >>>> capacity-scheduler -- move to MR core? >>>> data_join >>>> dynamic-scheduler >>>> eclipse-plugin >>>> fairscheduler -- move to MR core? >>>> gridmix >>>> index >>>> mrunit >>>> mumak >>>> raid >>>> sqoop >>>> streaming -- move to MR core? >>>> vaidya >>>> vertica >>>> >>>> >>>> HDFS Contrib: >>>> fuse-dfs >>>> hdfsproxy >>>> thriftfs >>>> >>>> >>>> Cheers, >>>> Nige >>>> >>> >
