So combining Mithun's proposal with the input from Sergey and Gopal, I
propose:
1) When a contributor provides a patch for a high priority bug (data
corruption, wrong results, crashes) he or she should also provide a
patch against the branch of the latest feature release. For example,
once Hive 0.14 is released that will mean providing patches for trunk
and the 0.14 branch. I believe the test infrastructure already supports
running the tests against alternate branches (is that correct Brock?) so
the patches can be tested against both trunk and the release branch.
2) The release manager of the feature release (e.g. Hive 0.14) will be
responsible for maintaining the branch with these patch fixes. It is
his or her call whether a given bug merits inclusion on the branch. If
a contributor provides a patch for trunk which in the release manager's
opinion should also be on the branch, then the release manager can ask
the contributor to also provide a patch for the branch. Since whoever
manages the feature release may not want to or be able to continue
managing the branch post release, these release manager duties are
transferable. But the transfer should be clear and announced on the dev
list.
3) In order to make these patch fixes available to Hive users we should
strive to have frequent maintenance releases. The frequency will depend
on the number of bug fixes going into branch, but 6-8 weeks seems like a
good goal.
Hive 0.14 could be the test run of this process to see what works and
what doesn't. Seem reasonable?
Alan.
Mithun Radhakrishnan <mailto:mithun.radhakrish...@yahoo.com.INVALID>
September 15, 2014 at 11:16
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.
Mithun
On Thursday, September 11, 2014 3:15 PM, Gopal V <gop...@apache.org>
wrote:
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.
Cheers,
Gopal
Gopal V <mailto:gop...@apache.org>
September 11, 2014 at 15:15
On 9/9/14, 1:52 PM, Mithun Radhakrishnan wrote:
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.
Cheers,
Gopal
--
Sent with Postbox <http://www.getpostbox.com>
--
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.
