-Re: Sqoop is moving to github!
Aaron Kimball 2010-03-30, 17:58
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]>
> > 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,
> > 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
> > working on it and the only person working on it is Aaron. If someone
> > to make a case for keeping Sqoop in MapReduce, please make it in the
> > 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
> > 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
> > that kind of cycle. Some projects like Zebra just live in the upper
> > (Pig in that case). The other option is to ask to be a sub-project, ask
> > join Apache incubator, or go to Github. Github doesn't give him the legal
> > community aspects of Apache, but it also doesn't require asking
> > 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.