hadoop-hdfs-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 Tue, 03 Mar 2015 15:59:01 GMT
Hi Akira, thanks for responding,

On Tue, Mar 3, 2015 at 4:04 AM, Akira AJISAKA <ajisakaa@oss.nttdata.co.jp>

> Thanks Andrew for bringing this up.
> +1 mostly looks fine but I'm thinking it's not now to cut branch-3.
> > classpath isolation
> IMHO, classpath isolation is a good thing to do.
> We should pay down the technical dept ASAP. I'm willing to help.
> I'm thinking we can cut branch-3 and release 3.0 alpha
> after HADOOP-11656 is fixed. That is, I'd like to mark
> this issue as a blocker for 3.0.
> I wonder that even if we cut branch-3 now, trunk and
> branch-3 would be the same for a while. That seems useless.
> I'm willing to wait a bit here, but I think even what we have now is worth
kicking the tires, and either the JDK8 target version or classpath
isolation would make it even more compelling.

If you're worried about backport overheads, Konst's proposal of releasing
directly from trunk might be appealing. Needs some more examination though.

> > JDK8
> As Steve suggested, JDK8 can be in both trunk and branch-2.
> +1 for moving to JDK8 ASAP.
> We can make sure branch-2 runs well under JDK8, but I'm against doing a
target version bump to JDK8 like we're planning to do for JDK7 in a minor
release. As I described in my reply to Arun, that was a special
circumstance, and JDK target version bumps really are deserving of a new
major release.

> > maintaining 2.x
> For user side, now there is little merit to upgrade to 3.x.
> More important thing is how long 2.x will be maintained.
> Therefore we should consider when to stop backporting
> new features to 2.x, and when to stop maintaining 2.x.
> I'd like to maintain 2.x as long as possible, at least
> one year after 3.x GA release.
> The value in releasing alphas right now is not so much for end users, but
for downstream projects which need time to integrate. I don't expect
end-users to really jump on 3.x until the downstreams have also rolled new
releases based on 3.x.

Determining when support for 2.x is over is done by the community. I
personally plan to keep backporting for a while after 3.x GA is released.
If backports to branch-2 tail off, it just takes one committer with the
interest to keep maintaining it. This has been a common thing in HBase for
instance, Lars H maintained 0.92 for a long time because he had the

> * Other issue
> What's the current status of HDFS symlink?
> If HADOOP-10019 requires some incompatible changes,
> I'd like to include in 3.x.
> There are still a lot of unresolved compatibility and security issues,
especially with cross-filesystem symlinks. We tabled this work before, and
frankly I'm not sure these issues will ever be satisfactorily resolved.
Even today, there are plenty of Unix apps that don't handle symlinks
correctly, and we still lack equivalents of more secure syscalls like
openat() in the first place.


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