> 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 -steve --------------------------------------------------------------------- To unsubscribe, e-mail: mapreduce-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org
