hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Shelukhin <ser...@hortonworks.com>
Subject Re: Patches to release branches
Date Tue, 09 Sep 2014 21:10:06 GMT
>From 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.


On Tue, Sep 9, 2014 at 1:52 PM, Mithun Radhakrishnan <
mithun.radhakrishnan@yahoo.com.invalid> wrote:

> Greetings, Hive Dev.
>
> 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.
>
> 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.
>
> 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:
>
> 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.
>
> 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. =]
>
> Thoughts?
>
> Mithun
>
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message