hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Chiang <rchi...@apache.org>
Subject Re: Branch merges and 3.0.0-beta1 scope
Date Tue, 22 Aug 2017 18:21:09 GMT
On 8/22/17 3:20 AM, Steve Loughran wrote:

>> On 21 Aug 2017, at 22:22, Vinod Kumar Vavilapalli <vinodkv@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.


To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

View raw message