> On 19 Aug 2017, at 02:22, Andrew Wang <andrew.w...@cloudera.com> wrote: > > * 3.0.0-beta1 includes S3Guard and YARN federation. Target date remains > mid-Sept. > * 3.0.0-GA includes TSv2 alpha2. Target date remains early November. > * Everything else waits for 3.1, approximately March 2018. >
probably time to create those releases in JIRA, so people can start explicitly targeting them. > On 19 Aug 2017, at 06:49, Vinod Kumar Vavilapalli <vino...@apache.org> wrote: > > Andrew, > > Each of the branches below have been created more than a year ago (!) and > have been consistently worked upon and are now finally seeing the light of > the day. When they are "few weeks” away, pushing them out by 7 *more* months > just doesn’t make sense. > > While I deeply appreciate the push for the dates, we shouldn’t be putting > moratorium on features like this till the proposed date is due. As a release > manager, it’s good to say that we will release a specific version as soon as > so-and-so features are in, but let’s not put exclusions like this. > > I propose that, as we have done with every release so far, (and more > specifically the way we did 2.x alphas, betas, GA back in the day), we float > the date, let the individual branch contributors decide their fate. As long > as of course, they meet the timelines and the usual branch merge bar, testing > / compatibility / impact on rest of the code-base etc. > > Anything short of that, we will just be incentivizing contributors away from > doing work in branches and towards putting stuff directly into trunk. > > +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
