hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin McCabe <cmcc...@alumni.cmu.edu>
Subject Re: Next releases
Date Fri, 06 Dec 2013 20:27:01 GMT
If 2.4 is released in January, I think it's very unlikely to include
symlinks.  There is still a lot of work to be done before they're
usable.  You can look at the progress on HADOOP-10019.  For some of
the subtasks, it will require some community discussion before any
code can be written.

For better or worse, symlinks have not been requested by users as
often as features like NFS export, HDFS caching, ACLs, etc, so effort
has been focused on those instead.

For now, I think we should put the symlinks-disabling patches
(HADOOP-10020, etc) into branch-2, so that they will be part of the
next releases without additional effort.

I would like to see HDFS caching make it into 2.4.  The APIs and
implementation are beginning to stabilize, and around January it
should be ok to backport to a stable branch.


On Thu, Dec 5, 2013 at 3:57 PM, Arun C Murthy <acm@hortonworks.com> wrote:
> Ok, I've updated https://wiki.apache.org/hadoop/Roadmap with a initial strawman list
for hadoop-2.4 which I feel we can get out in Jan.
> What else would folks like to see? Please keep timeframe in mind.
> thanks,
> Arun
> On Dec 2, 2013, at 10:55 AM, Arun C Murthy <acm@hortonworks.com> wrote:
>> On Nov 13, 2013, at 1:55 PM, Jason Lowe <jlowe@yahoo-inc.com> wrote:
>>> +1 to limiting checkins of patch releases to Blockers/Criticals.  If necessary
committers check into trunk/branch-2 only and defer to the patch release manager for the patch
release merge.  Then there should be fewer surprises for everyone what ended up in a patch
release and less likely the patch release becomes destabilized from the sheer amount of code
churn.  Maybe this won't be necessary if everyone understands that the patch release isn't
the only way to get a change out in timely manner.
>> I've updated https://wiki.apache.org/hadoop/Roadmap to reflect that we only put in
Blocker/Critical bugs into Point Releases.
>> Committers, from now, please exercise extreme caution when committing to a point
release: they should only be limited to Blocker bugs.
>> thanks,
>> Arun
> --
> Arun C. Murthy
> Hortonworks Inc.
> http://hortonworks.com/
> --
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.

View raw message