IMHO, when we propose any feature branch merge, we might need to consider following aspects
1)Use cases 2) Pluggable ---> if it's not pluggable , give the reason 3) API Compatibility 4) Impact-------> when it's enable 5) Performance 6) Stability 7) Test Sufficiency 8) Documentation Above points helps to validate the feature quality at first glance and based on that further consideration to merge can be done. --Brahma Reddy Battula -----Original Message----- From: Wangda Tan [mailto:wheele...@gmail.com] Sent: 22 August 2017 06:27 To: Vinod Kumar Vavilapalli Cc: Steve Loughran; Andrew Wang; common-...@hadoop.apache.org; hdfs-...@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-...@hadoop.apache.org Subject: Re: Branch merges and 3.0.0-beta1 scope Andrew, Thanks for your help to pushing this release. Echoing what Vinod said, all contributors in these branches are putting months to years of time working on these features, we don't have to decide excluded features now since we have 25 days till 3.0-beta1 planned release time. The best approach to stabilize feature is to let people try that, instead of waiting for feature becomes perfect. For features which can be turned off, I think we should consider to bring it in if it is end-to-end ready. I will try best to help merge efforts of YARN-3926 branch to trunk before Sep 15, and I'm OK with moving to the next release train if we fail to merge the feature before release date. Thanks, Wangda On Mon, Aug 21, 2017 at 2:22 PM, Vinod Kumar Vavilapalli <vino...@apache.org > wrote: > Steve, > > You can be strict & ruthless about the timelines. Anything that > doesn’t get in by mid-September, as was originally planned, can move > to the next release - whether it is feature work on branches or feature work > on trunk. > > The problem I see here is that code & branches being worked on for a > year are now (apparently) close to being done and we are telling them > to hold for 7 more months - this is not a reasonable ask.. > > If you are advocating for a 3.1 plan, I’m sure one of these branch > ‘owners’ can volunteer. But this is how you get competing releases and > split bandwidth. > > As for compatibility / testing etc, it seems like there is a belief > that the current ‘scoped’ features are all tested well in these areas > and so adding more is going to hurt the release. There is no way this > is the reality, trunk has so many features that have been landing for > years, the only way we can collectively attempt towards making this > stable is by getting as many parties together as possible, each > verifying stuff that they need. Not by excluding specific features. > > +Vinod > > > This is one of those curse-of-cadence things: The higher your > > release > cadence, the less pressure to get "everything in". With a slower > cadence, more pressure to get stuff in, more pressure to hold up the > release, slows the cadence, gets even more stuff in, etc. etc. > > > > - Andrew has been working on the release for months, we all need to > appreciate how much hard work that is and has been, especially for > what is going to be a major release. > > > > - We know that things will be unstable in 3.0; Andrew's concern is > > about > making sure that the newest, unstablest (?) features can at least be > bypassed if there are problems. I we should also call out in the > release notes what we think are the unstable bits where people need to > use caution > (example: S3Guard in "authoritative" mode) > > > > - Anything related to wire compatibility has been problematic in the > past; I think it's essential that whatever packets get sent around are > going to be stable, so changes there need to be in, or at least the > payloads set up ready for the features. Same for new public APIs. > > > > - As fpr the rest, I don't know. I think being strict about it and > ruthless in assessing the feature's stability & consequences of > postponing the feature until a Hadoop 3.1 release in Jan/Feb, with a > plan to ship then and follow up with a 3.2 in the summer. > > > > Then: start planning that 3.1 release. Maybe I should put my hand up > > as > release manager for that one. Then everyone would realise how amenable > Andrew is being today. > > > > > > One other thing: alongside the big branches, there's the eternal > > backlog > of small patches. We should organise spending a few days updating, > reviewing & merging them in > > > > -Steve > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org > > <mailto: > hdfs-dev-unsubscr...@hadoop.apache.org> > > For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org > <mailto:hdfs-dev-h...@hadoop.apache.org> > --------------------------------------------------------------------- To unsubscribe, e-mail: mapreduce-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org
