hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kumar Vavilapalli <vino...@apache.org>
Subject Re: Branch merges and 3.0.0-beta1 scope
Date Mon, 21 Aug 2017 21:22:33 GMT

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

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


> 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-unsubscribe@hadoop.apache.org <mailto:hdfs-dev-unsubscribe@hadoop.apache.org>
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org <mailto:hdfs-dev-help@hadoop.apache.org>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message