hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions
Date Thu, 16 Jul 2015 08:59:05 GMT

1. I agree that the bar for patches going in should be very high: there's always the risk
of some subtle regression. The more patches, the higher the risk, the more traumatic the update

2. I like the idea of having a list of proposed candidate patches, all of which can be reviewed
and discussed before going in. 

> On 16 Jul 2015, at 02:43, Vinod Kumar Vavilapalli <vinodkv@hortonworks.com> wrote:
> 
> https://issues.apache.org/jira/issues/?jql=labels%20%3D%202.6.1-candidate<https://issues.apache.org/jira/issues/?jql=labels%20=%202.6.1-candidate>


Link is https://issues.apache.org/jira/browse/YARN-3575?jql=labels%20%3D%202.6.1-candidate

3. Maybe we should have some guidelines of what isn't going to get in except in very, very
special cases

-any change to classpath/dependencies
-any change to the signature of an API, including exception types & text
-changes to wire formats

4. We could also consider driving patches based on those that downstream redistributors of
Hadoop felt were important enough to backport. That's cloudera as well as us, Amazon if they
filed JIRAs, Microsoft, + others. Ideally patches that have been tested and released, so there's
a high chance regressions would have surfaced already.

5. Then there's the "these broke HBase changes"; vinod already has HADOOP-11710 in there,
as an example.

6. And of course, any security issue patch should go in.

Overall then: the expectation should be that patches won't go in by default, unless viewed
as critical. We have to be ruthless, and people shouldn't commit things without getting approval
from others.

-Steve

Mime
View raw message