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:
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 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.
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
