Xuefu Zhang <mailto:xzh...@cloudera.com>
May 15, 2015 at 17:31
Just make sure that I understand the proposal correctly: we are going to
have two main branches, one for hadoop-1 and one for hadoop-2.
We shouldn't tie this to hadoop-1 and 2. It's about Hive not Hadoop.
It will be some time before Hive's branch-2 is stable, while Hadoop-2 is
already well established.
New features
are only merged to branch-2. That essentially says we stop development for
hadoop-1, right?
If developers want to keep contributing patches to branch-1 then there's
no need for it to stop. We would want to avoid putting new features
only on branch-1, unless they only made sense in that context. But I
assume we'll see people contributing to branch-1 for some time.
Are we also making two lines of releases: ene for branch-1
and one for branch-2? Won't that be confusing and also burdensome if we
release say 1.3, 2.0, 2.1, 1.4...
I'm asserting that it will be less confusing than the alternatives. We
need some way to make early releases of many of the new features. I
believe that this proposal is less confusing than if we start putting
the new features in 1.x branches. This is particularly true because it
would help us to start being able to drop older functionality like
Hadoop-1 and MapReduce, which is very hard to do in the 1.x line without
stranding users.
Please note that we will have hadoop 3 soon. What's the story there?
As I said above, I don't see this as tied to Hadoop versions.
Alan.
Thanks,
Xuefu
On Fri, May 15, 2015 at 4:43 PM, Vaibhav Gumashta<vgumas...@hortonworks.com
wrote:
+1 on the new branch. I think it’ll help in faster dev time for these
important changes.
—Vaibhav
From: Alan Gates<alanfga...@gmail.com>
Reply-To: "dev@hive.apache.org"<dev@hive.apache.org>
Date: Friday, May 15, 2015 at 4:11 PM
To: "dev@hive.apache.org"<dev@hive.apache.org>
Subject: Re: [DISCUSS] Supporting Hadoop-1 and experimental features
Anyone else have feedback on this? If not I'll start a vote next week.
Alan.
Gopal Vijayaraghavan<gop...@apache.org>
May 14, 2015 at 10:44
Hi,
+1 on the idea.
Having a stable release branch with ongoing fixes where we do not drop
major features would be good all around.
It lets us accelerate the pace of development, drop major features or
rewrite them entirely without dragging everyone else kicking& screaming
into that release.
Cheers,
Gopal
Sergey Shelukhin<ser...@hortonworks.com>
May 11, 2015 at 19:17
That sounds like a good idea.
Some features could be back ported to branch-1 if viable, but at least new
stuff would not be burdened by Hadoop 1/MR code paths.
Probably also a good place to enable vectorization and other perf features
by default while we make alpha releases.
+1
Alan Gates<alanfga...@gmail.com>
May 11, 2015 at 15:38
There is a lot of forward-looking work going on in various branches of
Hive: LLAP, the HBase metastore, and the work to drop the CLI. It would
be good to have a way to release this code to users so that they can
experiment with it. Releasing it will also provide feedback to developers.
At the same time there are discussions on whether to keep supporting
Hadoop-1. The burden of supporting older, less used functionality such as
Hadoop-1 is becoming ever harder as many new features are added.
I propose that the best way to deal with this would be to make a
branch-1. We could continue to make new feature releases off of this
branch (1.3, 1.4, etc.). This branch would not drop old functionality.
This provides stability and continuity for users and developers.
We could then merge these new features branches (LLAP, HBase metastore,
CLI drop) into the trunk, as well as turn on by default newer features such
as the vectorization and ACID. We could also drop older, less used
features such as support for Hadoop-1 and MapReduce. It will be a while
before we are ready to make stable, production ready releases of this
code. But we could start making alpha quality releases soon. We would
call these releases 2.x, to stress the non-backward compatible changes such
as dropping Hadoop-1. This will give users a chance to play with the new
code and developers a chance to get feedback.
Thoughts?
Vaibhav Gumashta <mailto:vgumas...@hortonworks.com>
May 15, 2015 at 16:43
+1 on the new branch. I think it’ll help in faster dev time for these
important changes.
—Vaibhav
From: Alan Gates <alanfga...@gmail.com <mailto:alanfga...@gmail.com>>
Reply-To: "dev@hive.apache.org <mailto:dev@hive.apache.org>"
<dev@hive.apache.org <mailto:dev@hive.apache.org>>
Date: Friday, May 15, 2015 at 4:11 PM
To: "dev@hive.apache.org <mailto:dev@hive.apache.org>"
<dev@hive.apache.org <mailto:dev@hive.apache.org>>
Subject: Re: [DISCUSS] Supporting Hadoop-1 and experimental features
Anyone else have feedback on this? If not I'll start a vote next week.
Alan.
Gopal Vijayaraghavan <mailto:gop...@apache.org>
May 14, 2015 at 10:44
Hi,
+1 on the idea.
Having a stable release branch with ongoing fixes where we do not drop
major features would be good all around.
It lets us accelerate the pace of development, drop major features or
rewrite them entirely without dragging everyone else kicking & screaming
into that release.
Cheers,
Gopal
Sergey Shelukhin <mailto:ser...@hortonworks.com>
May 11, 2015 at 19:17
That sounds like a good idea.
Some features could be back ported to branch-1 if viable, but at least new
stuff would not be burdened by Hadoop 1/MR code paths.
Probably also a good place to enable vectorization and other perf features
by default while we make alpha releases.
+1
Alan Gates <mailto:alanfga...@gmail.com>
May 11, 2015 at 15:38
There is a lot of forward-looking work going on in various branches of
Hive: LLAP, the HBase metastore, and the work to drop the CLI. It
would be good to have a way to release this code to users so that they
can experiment with it. Releasing it will also provide feedback to
developers.
At the same time there are discussions on whether to keep supporting
Hadoop-1. The burden of supporting older, less used functionality
such as Hadoop-1 is becoming ever harder as many new features are added.
I propose that the best way to deal with this would be to make a
branch-1. We could continue to make new feature releases off of this
branch (1.3, 1.4, etc.). This branch would not drop old
functionality. This provides stability and continuity for users and
developers.
We could then merge these new features branches (LLAP, HBase
metastore, CLI drop) into the trunk, as well as turn on by default
newer features such as the vectorization and ACID. We could also drop
older, less used features such as support for Hadoop-1 and MapReduce.
It will be a while before we are ready to make stable, production
ready releases of this code. But we could start making alpha quality
releases soon. We would call these releases 2.x, to stress the
non-backward compatible changes such as dropping Hadoop-1. This will
give users a chance to play with the new code and developers a chance
to get feedback.
Thoughts?
