hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro Abdelnur <t...@cloudera.com>
Subject Re: Hadoop Tools Layout (was Re: DistCpV2 in 0.23)
Date Wed, 07 Sep 2011 01:55:10 GMT
Eric,

Personally I'm fine either way.

Still, I fail to see why a generic/categorized tools increase/reduce the
risk of dead code and how they make more-difficult/easier the
package&deployment.

Would you please explain this?

Thanks.

Alejandro

On Tue, Sep 6, 2011 at 6:38 PM, Eric Yang <eric818@gmail.com> wrote:

> Option #2 proposed by Amareshwari, seems like a better proposal.  We don't
> want to repeat history for contrib again with hadoop-tools.  Having a
> generic module like hadoop-tools increases the risk of accumulate dead code.
>  It would be better to categorize the hdfs or mapreduce specific tools in
> their respected subcategories.  It is also easier to manage from
> package/deployment prospective.
>
> regards,
> Eric
>
> On Sep 6, 2011, at 4:32 PM, Eli Collins wrote:
>
> > On Tue, Sep 6, 2011 at 10:11 AM, Allen Wittenauer <aw@apache.org> wrote:
> >>
> >> On Sep 6, 2011, at 9:30 AM, Vinod Kumar Vavilapalli wrote:
> >>> We still need to answer Amareshwari's question (2) she asked some time
> back
> >>> about the automated code compilation and test execution of the tools
> module.
> >>
> >>
> >>
> >>>>> My #1 question is if tools is basically contrib reborn.  If not,
what
> >>>> makes
> >>>>> it different?
> >>
> >>
> >>        I'm still waiting for this answer as well.
> >>
> >>        Until such, I would be pretty much against a tools module.
>  Changing the name of the dumping ground doesn't make it any less of a
> dumping ground.
> >
> > IMO if the tools module only gets stuff like distcp that's maintained
> > then it's not contrib, if it contains all the stuff from the current
> > MR contrib then tools is just a re-labeling of contrib. Given that
> > this proposal only covers moving distcp to tools it doesn't sound like
> > contrib to me.
> >
> > Thanks,
> > Eli
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message