Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Bigtop >> mail # dev >> [DISCUSS] BOM for release 0.7.0 of Bigtop


Copy link to this message
-
Re: [DISCUSS] BOM for release 0.7.0 of Bigtop
To start with I don't even understand what it means 'make version X a
default'. All components including into BOM are equal, except for Hadoop that
is more equal than others ;)

At any rate: bleeding edge mantra is just what we like to present Bigtop, it
isn't really a policy of the project. Besides, Bigtop 0.6.0 was used as a
stabilization of the stack based on Hadoop 2.0.x, namely 2.0.5

Another alternative to having Sqoop 1.x returned is too quickly bake 0.6.1
(along with Bruno's original idea), but with a single change in its BOM, ie
Sqoop 1.x added into it.
The scope of the release would be really limited, e.g. just one JIRA, and we
should be able to get it out in a matter of a couple of days without
disrupting 0.7.0.  If this seems like a good way to go - let's separate these
two and keep pn 0.7.0 discussion.

Thoughts,
  Cos

On Tue, Jul 09, 2013 at 05:19PM, Mark Grover wrote:
> I am inclined against making Sqoop1 the default version in Bigtop precisely
> because of the point Andrew raised. Moreover, we had some good reasons when
> we moved to Sqoop2 that resonated with Bigtop's charter of a cutting edge
> distribution and helping in the stabilization of Hadoop ecosystem projects.
> More details at https://issues.apache.org/jira/browse/BIGTOP-805
>
> As far as adding back Sqoop1 back to Bigtop is concerned, this is a
> community led project, so if the community wants it, it will happen:-) The
> general sentiment when introducing Sqoop2 was that there wasn't a need for
> having 2 versions of Sqoop. From poking around, I think we did the same for
> Flume when migrating from Flume OG to Flume NG (
> https://issues.apache.org/jira/browse/BIGTOP-323).
>
> As far as Sqoop2 being preview releases, one could argue that the Hadoop
> releases bigtop bundles are preview as well. In my personal opinion, the
> charter of Bigtop, is to be that very cutting edge well tested distribution
> that helps in stabilizing them along the way. Personally, I feel like
> Sqoop2 being default falls in line with that. Given the above, I would
> personally vote for Sqoop2 being present in BOM. And, adding Sqoop1 back in
> as non-default Sqoop if there is traction in the community.
>
> I am open to feedback, though. What do others think?
>
> Mark
>
> On Tue, Jul 9, 2013 at 4:42 PM, Venkat Ranganathan <
> [EMAIL PROTECTED]> wrote:
>
> > I understand.  The discussion we had was around the current distributions
> > ship with Sqoop 1.x as the default sqoop product (primarily because Sqoop 2
> > is in preview releases currently.   The current focus of the team is to
> > bring sqoop 2 to fruition quickly but Sqoop 1.x is the release that
> > customers currently are  using and hence the suggestion.
> >
> > Venkat
> >
> >
> > On Tue, Jul 9, 2013 at 2:58 PM, Andrew Purtell <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Tue, Jul 9, 2013 at 2:52 PM, Venkat Ranganathan <
> > > [EMAIL PROTECTED]> wrote:
> > >
> > > > I would also suggest we revert back to
> > > > making Sqoop 1 the default sqoop version
> > > >
> > >
> > > Wouldn't that make an upgrade from Bigtop 0.6 to 0.7 a Sqoop downgrade?
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >    - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > > (via Tom White)
> > >
> >