hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arun C Murthy <...@hortonworks.com>
Subject Re: [VOTE] Release Apache Hadoop 2.1.0-beta
Date Mon, 29 Jul 2013 22:00:16 GMT
Ok, I think we are close to rc1 now - the last of blockers should be committed later today…
I'll try and spin RC1 tonight.

thanks,
Arun

On Jul 21, 2013, at 12:43 AM, Devaraj Das <ddas@hortonworks.com> wrote:

> I have just raised https://issues.apache.org/jira/browse/HDFS-5016 .. This
> bug can easily be reproduced by some HBase tests. I'd like this to be
> considered before we make a beta release. Have spoken about this with some
> hdfs folks offline and I am told that it is being worked on.
> 
> Thanks
> Devaraj
> 
> 
> On Wed, Jul 17, 2013 at 4:25 PM, Alejandro Abdelnur <tucu00@gmail.com>wrote:
> 
>> As I've mentioned in my previous email, if we get YARN-701 in, we should
>> also get in the fix for unmanaged AMs in an un-secure setup in 2.1.0-beta.
>> Else is a regression of a functionality it is already working.
>> 
>> Because of that, to avoid continuing delaying the release, I'm suggesting
>> to mention in the release notes the API changes and behavior changes that
>> YARN-918 and YARN-701 will bring into the next beta or GA release.
>> 
>> thx
>> 
>> 
>> On Wed, Jul 17, 2013 at 4:14 PM, Vinod Kumar Vavilapalli <
>> vinodkv@hortonworks.com> wrote:
>> 
>>> 
>>> On Jul 17, 2013, at 1:04 PM, Alejandro Abdelnur wrote:
>>> 
>>>> * YARN-701
>>>> 
>>>> It should be addressed before a GA release.
>>>> 
>>>> Still, as it is this breaks unmanaged AMs and to me
>>>> that would be a blocker for the beta.
>>>> 
>>>> YARN-701 and the unmanaged AMs fix should be committed
>>>> in tandem.
>>>> 
>>>> * YARN-918
>>>> 
>>>> It is a consequence of YARN-701 and depends on it.
>>> 
>>> 
>>> 
>>> YARN-918 is an API change. And YARN-701 is a behaviour change. We need
>>> both in 2.1.0.
>>> 
>>> 
>>> 
>>>> * YARN-926
>>>> 
>>>> It would be nice to have it addressed before GA release.
>>> 
>>> 
>>> Either ways. I'd get it in sooner than later specifically when we are
>>> trying to replace the old API with the new one.
>>> 
>>> Thanks,
>>> +Vino
>>> 
>>> 
>> 

--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/



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