On 8/22/17 3:20 AM, Steve Loughran wrote:
On 21 Aug 2017, at 22:22, 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.
If everyone is confident & its coming together, it does make sense. I think
those of us (myself included) who are merging stuff in do have to recognise that we
really need to follow it through by being responsive to any problem -and with the
release manager having the right to pull things out if its felt to be significantly
threatening the stability of the final 3.0 release.
I think we should also consider making the 3.0 beta the feature freeze; after that fixes
on the features go in, but nothing else of significance, otherwise the value of the beta
"test this code more broadly" is diminoshed
At this point, there have been three planned alphas from September 2016
until July 2017 to "get in features". While a couple of upcoming
features are "a few weeks" away, I think all of us are aware how
predictable software development schedules can be. I think we can also
all agree that rushing just to meet a release deadline isn't the best
practice when it comes to software development either.
Andrew has been very clear about his goals at each step and I think
Wangda's willingness to not rush in resource types was an appropriate
response. I'm sympathetic to the goals of getting in a feature for 3.0,
but it might be a good idea for each project that is a "few weeks away"
to seriously look at the readiness compared to the features which have
been testing for 6+ months already.
-Ray
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org
