Mailing-List: contact dev-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Received-SPF: pass (nike.apache.org: domain of mithun.radhakrishnan@yahoo.com
 designates 98.139.212.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com;
	b=ODQDiJKocPyzHKbFt0oE7ZsQ2ADl9hbFLJksHt+Ys0pIP84vLIUPXJSUvtIp7VcuaZULEmVZXYynQA19NwgDWSJr9YtFFq0Q3IEKBF/5lonTzXJDwLJqy25m/7vEam2h+g2RkTL9GK6FQvv5ZhN1fS2mVu0FzFUcfnCDivLg/5VwOCHUMlxkonOnX9GPL3GKShaTz1xGM2MZ1iJMohxRzRrAmPwU1xJIGqQyqf31YW0ZcfckMn0+3uZ+XE/f/vcWHthm/tJRbSF3i7ZuVqLEWEFYNrKja656nQsnXIdpPf2PCRwZgSV7LZYVXrTt3u0wqmS9pZEiC8O56pnLJ8oLug==;
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Patches to release branches
From: Mithun Radhakrishnan <mithun.radhakrishnan@yahoo.com.INVALID>
In-Reply-To: 
 <CAHXxaiBs8L-+S2SsWMV-0=NqjGqgKzMh701zCdYHdkJ8rt9fZg@mail.gmail.com>
Date: Wed, 10 Sep 2014 12:49:46 -0700
Cc: "hive-dev@hadoop.apache.org" <hive-dev@hadoop.apache.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C53FC89-EA6B-45D8-91E0-942D9800AB56@yahoo.com>
References: <1410295941.99389.YahooMailNeo@web162103.mail.bf1.yahoo.com>
 <CAHXxaiBs8L-+S2SsWMV-0=NqjGqgKzMh701zCdYHdkJ8rt9fZg@mail.gmail.com>
To: dev@hive.apache.org

Hello, Sergey.

I=92m actually talking about the release-branches, not the release =
itself. I=92m not as concerned about the release artifacts that we=92ve =
pushed out (e.g. for download from Apache, or the maven artifacts). I=92m =
more concerned about the release branch itself not getting the critical =
fixes that are available on trunk.

I=92d like for us to keep the latest release *branch* current with =
critical fixes. I can understand that this means changing the branch off =
of which the release was made=85 In which case, maybe it makes sense to =
keep another branch going with the updates. The release manager might =
then choose to make a point-release off of that branch. But IMHO, it =
can=92t be acceptable not to have these fixes available/applicable to =
the branch for the latest release.=20

Mithun

On Sep 9, 2014, at 2:10 PM, Sergey Shelukhin <sergey@hortonworks.com> =
wrote:

> =46rom my experience in HBase, I can say that bug fix (or "dot", e.g. =
0.96.1)
> releases are a common practice and work very well for users. The =
release
> manager of the corresponding major release vets the backports and =
makes
> bugfix releases on some cadence (i.e. monthly), without much of the =
usual
> major release overhead.
>=20
>=20
> On Tue, Sep 9, 2014 at 1:52 PM, Mithun Radhakrishnan <
> mithun.radhakrishnan@yahoo.com.invalid> wrote:
>=20
>> Greetings, Hive Dev.
>>=20
>> In the past few months, my colleagues and I have been trying to roll =
Hive
>> 0.13 out for wider use on Yahoo's Hadoop clusters. A "challenging"
>> endeavour, shall we say.
>>=20
>> Back when we were rolling out Hive 0.12, in spite of basing our =
builds on
>> the Apache Hive 0.12 release branch, we ran into *several* problems =
that we
>> wouldn't want to roll into production. (These have variously involved =
the
>> ORC file-format, dynamic partitioning, metastore performance, =
query-plan
>> serialization, and so on.) On the bright side, most of what we ran =
into was
>> already found and rectified on trunk (now Hive 0.13). But those fixes
>> didn't uniformly make it back to branch-0.12, then the current stable
>> release. I fear we're now repeating this with Hive 0.13.
>>=20
>> We've found that keeping up with the fixes on trunk is like trying to
>> board a moving train while also trying to pull our shoes on. Patches =
often
>> don't cleanly apply back to a release-branch because of unrelated =
changes
>> on trunk. They sometimes depend silently on changes elsewhere. When =
we're
>> lucky, tests fail. And when we're not, things go hilariously =
pear-shaped in
>> production. Permit me the temerity of making the following =
suggestion:
>>=20
>> 1. For P1 bugs (i.e. involving data corruption, service =
unavailability, or
>> serious failures without reasonable workarounds), along with a fix =
for
>> trunk, I move that the current stable release branch also be patched. =
This
>> will be much easier to accomplish alongside the trunk fix, than =
months down
>> the line.
>> 2. Of *course*, this doesn't apply to new features on trunk.
>>=20
>> I realize this will involve a greater commitment from us (the =
community),
>> certainly more effort for testing. But it'll ensure that current =
stable
>> Hive release is both current and stable. =3D]
>>=20
>> Thoughts?
>>=20
>> Mithun
>>=20
>>=20
>=20
> --=20
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or =
entity to=20
> which it is addressed and may contain information that is =
confidential,=20
> privileged and exempt from disclosure under applicable law. If the =
reader=20
> of this message is not the intended recipient, you are hereby notified =
that=20
> any printing, copying, dissemination, distribution, disclosure or=20
> forwarding of this communication is strictly prohibited. If you have=20=

> received this communication in error, please contact the sender =
immediately=20
> and delete it from your system. Thank You.