hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mithun Radhakrishnan <>
Subject Re: Patches to release branches
Date Mon, 15 Sep 2014 18:16:48 GMT
Hey, Gopal. 
Thank you, that makes sense. I'll concede that delaying the initial commit till a patch is
available for the recent-most release-branch won't always be viable. While I'd expect it
to be easier to patch the release-branch early than late, if we (the community) would prefer
a cloned JIRA in a separate queue, of course I'll go along. Anything to make the release-branch
usable out of the box, without further patching. 
Forgive my ignorance of the relevant protocol... Would this be a change in release/patch process?
Does this need "codifying"? I'm not sure if this needs voting on, or even who might call a
vote on this.

     On Thursday, September 11, 2014 3:15 PM, Gopal V <> wrote:

 On 9/9/14, 1:52 PM, Mithun Radhakrishnan wrote:

> 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
> release branch also be patched. This will be much easier to accomplish alongside the
> fix, than months down the line.
> 2. Of *course*, this doesn't apply to new features on trunk.

This is a very sensible proposal.

As a start, I think we need to have people open backport JIRAs, for such 
issues - even if a direct merge might be hard to do with the same patch.

Immediately cherry-picking the same patch should be done if it applies 
with very little modifications - but reworking the patch for an older 
release is a significant overhead for the initial commit.

At the very least, we need to get past the unknowns that currently 
surround the last point release against the bugs already fixed in trunk.

Once we have a backport queue, I'm sure the RMs in charge of the branch 
can moderate the community on the complexity and risk factors involved.


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