hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: Looking to a Hadoop 3 release
Date Sun, 21 Feb 2016 05:07:13 GMT
Hi Junping, thanks for the mail, inline:

On Sat, Feb 20, 2016 at 7:34 AM, Junping Du <jdu@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


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