+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" <ste...@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 < > vino...@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 >
