As long as someone volunteer to add a sqoop1 package for 0.7.0 or 0.6.1,
I don't have any issue with it.
The only thing I care about is to not go back in versions and to not
break upgrades.
So if commands or path conflicts (sqoop1 vs sqoop2), then sqoop 2 should
take priority.
Thanks,
Bruno
On 07/09/2013 09:10 PM, Konstantin Boudnik wrote:
Ah, make sense. It looks like having both version might be a mess... Shall we
stick with the plan of having Sqoop1 restored just in 0.6.1 then ?
On Tue, Jul 09, 2013 at 09:06PM, Sean Mackrory wrote:
To start with I don't even understand what it means 'make version X a default'
I think what they/we mean is which one gets to be called just "sqoop"
in the directories and command names, and which one has its version as
a suffix (e.g. "sqoop1", "sqoop2"). Alternatively they could both have
the suffix. I don't feel that strongly any particular way, just
clarifying what I think is meant.
On Tue, Jul 9, 2013 at 7:51 PM, Konstantin Boudnik <[email protected]> wrote:
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)
