I kind of echo Junping’s comment too. While 2.8 and 3.0 don’t need to be serialized in theory, in practice I’m desperately looking for help on 2.8.0. We haven’t been converging on 2.8.0 what with 50+ blocker / critical patches still unfinished. If postponing 3.x alpha to after a 2.8.0 alpha means undivided attention from the community, I’d strongly root for such a proposal.
Thanks +Vinod > On Feb 20, 2016, at 9:07 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > > Hi Junping, thanks for the mail, inline: > > On Sat, Feb 20, 2016 at 7:34 AM, Junping Du <j...@hortonworks.com> wrote: > >> Shall we consolidate effort for 2.8.0 and 3.0.0? It doesn't sounds >> reasonable to have two alpha releases to go in parallel. Is EC feature the >> main motivation of releasing hadoop 3 here? If so, I don't understand why >> this feature cannot land on 2.8.x or 2.9.x as an alpha feature. >> > > EC is one motivation, there are others too (JDK8, shell scripts, jar > bumps). I'm open to EC going into branch-2, but I haven't seen any > backporting yet and it's a lot of code. > > >> If we release 3.0 in a month like plan proposed below, it means we will >> have 4 active releases going in parallel - two alpha releases (2.8 and 3.0) >> and two stable releases (2.6.x and 2.7.x). It brings a lot of challenges in >> issues tracking and patch committing, not even mention the tremendous >> effort of release verification and voting. >> I would like to propose to wait 2.8 release become stable (may be 2nd >> release in 2.8 branch cause first release is alpha due to discussion in >> another email thread), then we can move to 3.0 as the only alpha release. >> In the meantime, we can bring more significant features (like ATS v2, etc.) >> to trunk and consolidate stable releases in 2.6.x and 2.7.x. I believe that >> make life easier. :) >> Thoughts? >> >> Based on some earlier mails in this chain, I was planning to release off > trunk. This way we avoid having to commit to yet-another-branch, and makes > tracking easier since trunk will always be a superset of the branch-2's. > This does mean though that trunk needs to be stable, and we need to be more > judicious with branch merges, and quickly revert broken code. > > Regarding RM/voting/validation efforts, Steve mentioned some scripts that > he uses to automate Slider releases. This is something I'd like to bring > over to Hadoop. Ideally, publishing an RC is push-button, and it comes with > automated validation. I think this will help with the overhead. Also, since > these will be early alphas, and there will be a lot of them, I'm not > expecting anyone to do endurance runs on a large cluster before casting a > +1. > > Best, > Andrew
