hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@altiscale.com>
Subject Re: In hindsight... Re: Thinking ahead to hadoop-2.6
Date Tue, 16 Sep 2014 05:53:33 GMT

On Sep 15, 2014, at 11:17 AM, Colin McCabe <cmccabe@alumni.cmu.edu> wrote:

> On Mon, Sep 15, 2014 at 10:48 AM, Allen Wittenauer <aw@altiscale.com> wrote:
>>        It’s now September.  With the passage of time, I have a lot of doubts about
this plan and where that trajectory takes us.
>> * The list of changes that are already in branch-2 scare the crap out of any risk
adverse person (Hello to my fellow operations people!). Not only are the number of changes
extremely high, but in addition there are a lot of major, blockbuster features in what is
supposed to be a minor release.  Combined with the fact that we’ve had to do some micro
releases, it seems to hint that branch-2 is getting less stable over time.
> I don't see what is so scary about 2.6, can you be more concrete?  It
> seems like a pretty normal release to me and most of the new features
> are optional.
> I also don't see why you think that "branch-2 is getting less stable
> over time."  Actually, I think that branch-2 has gotten more stable
> over time as people have finally gotten around to upgrading from 1.x
> or earlier, and contributed their efforts to addressing regressions in
> branch-2.

	Please re-read what I wrote above.

>> *  One of the plans talked about was rolling a 2.7 release that drops JDK6 and makes
JDK7 the standard.  If 2.7 comes after 2.6 in October, date wise  makes it somewhere around
January 2015.  JDK7 EOL’s in April 2015.  So we’ll have a viable JDK7 release for exactly
3 months.  Frankly, it is too late for us to talk about JDK7 and we need to start thinking
about JDK8.
>> * trunk is currently sitting at 3 years old.  There is a lot of stuff that has been
hanging around that really needs to get into people hands so that we can start stabilizing
it for a “real” release.
> We have been pretty careful about minimizing trunk's divergence from
> branch-2.  I can't think of an example of anything in trunk that
> "really needs to get into people's hands"-- did I forget something?

	There isn't anything in *any* of the recent branch-2 releases that qualifies as "really needs
to get into people's hands" either, so I'm not sure what your point here is.

>> To me this all says one thing:
>>        Drop the 2.6.0 release, branch trunk, and start rolling a 3.0.0-alpha with
JDK8 as the minimum.  2.5.1 becomes the base for all sustaining work.  This gives the rest
of the community time to move to JDK8 if they haven’t already.  For downstream vendors,
it gives a roadmap for their customers who will be asking about JDK8 sooner rather than later.
 By the time 3.0 stabilizes, we’re probably looking at April, which is perfect timing.
>>        One of the issues I’ve heard mention is that 3.0 doesn’t have anything
“compelling” in it.  Well, dropping 2.6 makes the feature list the carrot, JDK8 support
is obviously the stick.
>>        Thoughts?
> As we've discussed before, supporting JDK8 is very different from
> forcing people to use JDK8.  branch-2 and Hadoop 2.6 most certainly
> should support JDK8, and most certainly NOT force people to use JDK8.

	We aren't the ones forcing the JDK8 issue: Oracle is.  Users who want a viable, supported
JDK will be moving to 8 by April. 

> Cloudera has been using JDK7 internally for a long time, and
> recommending it to customers too.

	Thank you for using your vendor hat to support my point:  JDK7 works fine with Hadoop 2 now,
so those users who can't upgrade to JDK8 for whatever reason still have a viable option if
they want to use Hadoop.  After all, again as you point out above, all of the new bits are
optional features and could get pushed to a later release.  We can continue to make security
and critical bug fixes against 2.5.x and start pushing those optional features into a newly
viable 3.x release.  It also supports our major.minor.micro nomenclature as well as puts us
in line with a lot of other Apache projects. (as pointed out to me today: http://t.co/Ry8Zu6yZkd

> Some developers are using JDK8 as
> well.  It works fine (although I'm sure there will be bugs and
> workarounds that get reported and fixed as more people migrate).
	All of the people that I know that are doing JDK8 are applying patches to make it work. 
(See HADOOP-11090)

>  I don't see this particular issue as a reason to change the schedule.

	Look at this from a long-term perspective.  If we make the move to support JDK7 as the base
line in the next few months, we're essentially saying that we're willing to keep JDK7 working
for the next 3-4 years (given our normal JVM update process).  This isn't a viable strategy
given that Oracle (you know, the people that provide the JVM) is about to drop support/provide
updates in 7 months and JDK9 in early access with an expected ship date in 2016.  JDK7 will
be ancient at that point, even worse that JDK6 feels now.

View raw message