On Tue, Mar 30, 2010 at 7:54 AM, Bernd Fondermann < [email protected]> wrote:
> On Tue, Mar 30, 2010 at 15:48, Owen O'Malley <[email protected]> > wrote: > > On Tue, Mar 30, 2010 at 1:55 AM, Bernd Fondermann < > > [email protected]> wrote: > > > >> > >> @Hadoop PMC: What is your statement on this fork announcement? > > > > > > Aaron has been the primary developer of Sqoop. He has asked for it to be > > removed from MapReduce's contrib. If a committer -1's the code removal, > it > > will cause a fork. But that hasn't happened and I don't think it will. > > It's not the contributor's code alone anymore, once it's been committed. > Where has this been discussed? Where's the PMC-level vote/record of > consensus to ratify to abandon the code? > (ML + TS will be sufficient and I'll find my way.) > > I believe that technically the discussion (such as it is) on MAPREDUCE-1644 will stand as the record of vote. It's still open for new comments. > > In > > order for it to make sense to keep the code in Hadoop, someone needs to > be > > working on it and the only person working on it is Aaron. If someone > wants > > to make a case for keeping Sqoop in MapReduce, please make it in the > jira: > > https://issues.apache.org/jira/browse/MAPREDUCE-1644 > > Well, at least someone reviewed and committed all the contributions to > svn in the first place, he can't be the only one working on it. > > Indeed. Hadoop committers have checked in all my contributions; Tom White has done the lion's share of this work. > > The sub-projects must avoid circular dependencies. We must be able to > build > > the sub-projects in order without having to go back and update a previous > > project. Making a component of MapReduce depend on Hive (or Pig) would > cause > > that kind of cycle. Some projects like Zebra just live in the upper > project > > (Pig in that case). The other option is to ask to be a sub-project, ask > to > > join Apache incubator, or go to Github. Github doesn't give him the legal > or > > community aspects of Apache, but it also doesn't require asking > permission > > or introduce any process requirements. > > Well, I'm not looking at this from the contributor's perspective here. > He can do with the code whatever he likes, basically. > It's only the PMC's viewpoint which is interesting for me. > > Bernd > - Aaron
