hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinayakumar B <vinayakum...@apache.org>
Subject Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions
Date Thu, 16 Jul 2015 09:25:44 GMT
+1 for steve's suggestion.
I agree completely that everything should be finalized before committing in.

-Vinay
On Jul 16, 2015 2:29 PM, "Steve Loughran" <stevel@hortonworks.com> wrote:

>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message