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
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.


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]>