Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

On Wed, Nov 23, 2011 at 5:40 PM, Arun C Murthy wrote: > Also, another way to get the RM's attention is to mark the 'Target Version' > along with the patch. Would be happy to do so. Wasn't sure what the proper protocol is. Sorry about that. As for the patch -- I'll add JIRA comments. Thanks, Rom

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

On Nov 23, 2011, at 5:35 PM, Arun Murthy wrote: > On Nov 23, 2011, at 5:32 PM, Roman Shaposhnik wrote: > >> Hi Matt, >> >> quick question: any reason we are ignoring multifilewc from hadoop examples? >> > > Roman - It isn't marked as a blocker nor is there a patch. > Also, another way to ge

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

On Nov 23, 2011, at 5:32 PM, Roman Shaposhnik wrote: > Hi Matt, > > quick question: any reason we are ignoring multifilewc from hadoop examples? > Roman - It isn't marked as a blocker nor is there a patch. Can you provide one? Arun > https://issues.apache.org/jira/browse/MAPREDUCE-3319 > > wo

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Hi Roman, Do you have a proposed patch? If so I would be happy to include it. Thanks, --Matt On Wed, Nov 23, 2011 at 5:14 PM, Roman Shaposhnik wrote: > Hi Matt, > > quick question: any reason we are ignoring multifilewc from hadoop > examples? > https://issues.apache.org/jira/browse/MAPREDUC

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Hi Matt, quick question: any reason we are ignoring multifilewc from hadoop examples? https://issues.apache.org/jira/browse/MAPREDUCE-3319 would be nice to fix it for 1.0 of Hadoop. Or at least disable. Thanks, Roman. On Wed, Nov 23, 2011 at 2:56 PM, Matt Foley wrote: > I really want this i

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Hi Eli, I said a couple weeks ago that I intended to cut 205.1 on Nov 11 -- that's the subject line of this thread :-) However, I got busy and did not make the 11/11/11 date, for which I apologize. In the meantime, a severe blocker bug, HADOOP-7853, has been found and fixed by folks at Yahoo, rel

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Hey Matt, On the jira Jitendra referenced a 205.1 deadline. Where did you set or communicate that deadline? The last I saw on the lists (this thread) was that the 205.1 code freeze was Nov 11th. Thanks, Eli On Wed, Nov 23, 2011 at 2:56 PM, Matt Foley wrote: > I really want this in 0.20.205.1,

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

I really want this in 0.20.205.1, which will be Hadoop 1.0.0, because of its importance for good support of HBase. Jitendra, please merge it to branch-0.20-security-205. --Matt (wearing my Apache release manager hat) On Wed, Nov 23, 2011 at 11:14 AM, Suresh Srinivas wrote: > +1 for Jitendra's

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

+1 for Jitendra's proposal. Additionally, most of the core of the code that this patch is based on has been tested and deployed in clusters at TrendMicro and Facebook. On Wed, Nov 23, 2011 at 11:10 AM, Jitendra Pandey wrote: > The trunk, 206 patches for HDFS-2246 have been committed. I think it

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

The trunk, 206 patches for HDFS-2246 have been committed. I think it makes sense to commit it to 205.1 as well for following reasons (most of it has already been mentioned) a) We intended this patch for 205, but couldn't finish in time. Now that 205.1 branch is still not cut, we could get this in.

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

On Fri, Nov 11, 2011 at 2:29 PM, Todd Lipcon wrote: > On Fri, Nov 11, 2011 at 1:29 AM, Matt Foley wrote: > >> >> Also, I believe in the HDFS-2246 Jira, Todd requested extra time to review, >> due to commitments at Hadoop World.  Todd, would Monday be sufficient extra >> time, so as not to slow do

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

From: Todd Lipcon > To: common-dev@hadoop.apache.org > Cc: > Sent: Friday, November 11, 2011 5:29 PM > Subject: Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 > Nov. > > On Fri, Nov 11, 2011 at 1:29 AM, Matt Foley > wrote: > >> >

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

On Fri, Nov 11, 2011 at 1:29 AM, Matt Foley wrote: > > Also, I believe in the HDFS-2246 Jira, Todd requested extra time to review, > due to commitments at Hadoop World.  Todd, would Monday be sufficient extra > time, so as not to slow down the anticipated release schedule too much? > Yes, I will

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

On Fri, Nov 11, 2011 at 1:41 PM, Nathan Roberts wrote: > Hi Matt, > > I propose the following for consideration for 0.20.205.1: > > https://issues.apache.org/jira/browse/HADOOP-7816 Allow Hadoop warning > suppression to be specified in config > + Improves workaround for a common usability complai

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Hi Matt, I propose the following for consideration for 0.20.205.1: https://issues.apache.org/jira/browse/HADOOP-7816 Allow Hadoop warning suppression to be specified in config + Improves workaround for a common usability complaint https://issues.apache.org/jira/browse/MAPREDUCE-2980- Fetch fail

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

As a heads up, this will require some tweaks in downstream projects. For example: https://issues.apache.org/jira/browse/HIVE-2570 Currently I cannot use Hive with Hadoop 0.20.20#.0 because of this. Thanks. Alejandro On Fri, Nov 11, 2011 at 10:34 AM, Eli Collins wrote: > Hey Matt, > > My und

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Hey Matt, My understanding of introducing the new 4 part version scheme was to provide stability. Eg if someone is running 0.20.205.0 wants to be able to get just critical bug fixes (maybe they don't even use HBase) to what they're running then they can use 205.1, .2 etc. If someone running 205 wa

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Hi Eli, The reason I am looking at HDFS-2246 for 205 is that I and a number of Hadoop and HBase community members really want 205 to have good support for HBase. This performance improvement turns out to be pretty important in order to actually have good support for HBase. In that sense, I'm incl

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

> I had spoken with Sanjay offline about this patch a week or so before > 205 was frozen. At that point we had left the discussion that we would > try to get it in for 205 with the understanding that a trunk patch > would be posted within a day or two of the 205 patch. Given that it's > now been a

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Hey guys, HDFS-2246 is not a fix, it's a non-trivial performance optimization. The roadmap page is pretty clear.. "Point releases are made to fix critical bugs. They do not introduce new features or make other improvements other than fixing bugs". I'm not opposed to the change, I'm just pointing

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

On Thu, Nov 10, 2011 at 9:58 PM, Suresh Srinivas wrote: > Eli, > > As Jitendra indicated in the jira, this was originally supposed to be part > of 0.205. Due to time crunc, we could not get this done in 0.205. This can > be turned off by a flag and only can be enabled by users who want to use > th

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Eli, As Jitendra indicated in the jira, this was originally supposed to be part of 0.205. Due to time crunc, we could not get this done in 0.205. This can be turned off by a flag and only can be enabled by users who want to use the functionality. Given that, I feel it is okay to go into 0.205.1.

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Hi Eli, There is no new functionality added by HDFS-2246. It is a "performance" fix. But I agree that it is not a trivial fix. One proposal coud be to commit this patch to trunk too and then continue to work on HDFS-347 to make a better fix to this problem. The godo part is that there is no API c

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Hey Matt, Is HDFS-2246 slated for 0.20.205.1? Given that it's not a bug and is non-trivial it seems better suited for 206 than a point release. Also, per the sustaining roadmap - http://wiki.apache.org/hadoop/Roadmap - "Only functionality already committed to trunk should be submitted to a sustai

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Hi all, *So far, the following patches have been committed and accepted for inclusion in 0.20.205.1:* *Key* *Assignee* *Reporter* *Summary* HADOOP-5124 Hairong Kuang Hairong Kuang A few optimizations to FsNamesystem#RecentInvalidateSets HADOOP-

Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Yes, please see request in the Jira. Thanks, --Matt On Mon, Nov 7, 2011 at 5:39 PM, Roman Shaposhnik wrote: > And here's another one that I would like to nominate based on Bigtop > testing: > https://issues.apache.org/jira/browse/MAPREDUCE-3374 > > Any chance of pulling this into the release?

RE: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

flag this for review? Thanks, - Tim. From: mfo...@hortonworks.com [mfo...@hortonworks.com] On Behalf Of Matt Foley [ma...@apache.org] Sent: Friday, November 04, 2011 5:56 PM To: common-dev@hadoop.apache.org Subject: [ANNOUNCE] Intend to build a

[ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.

Hi all, I propose to make a 0.20.205.1 candidate soon, with the following sets of patches: - deficiencies in HBase support, pointed out by the HBase team and others - deficiencies in webhdfs support on secure clusters - a couple last-minute fixes submitted to branch-0.20-security-205 that