Return-Path: Delivered-To: apmail-hadoop-hbase-dev-archive@minotaur.apache.org Received: (qmail 95752 invoked from network); 15 Apr 2010 06:13:56 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 15 Apr 2010 06:13:56 -0000 Received: (qmail 81038 invoked by uid 500); 15 Apr 2010 06:13:55 -0000 Delivered-To: apmail-hadoop-hbase-dev-archive@hadoop.apache.org Received: (qmail 81012 invoked by uid 500); 15 Apr 2010 06:13:55 -0000 Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hbase-dev@hadoop.apache.org Delivered-To: mailing list hbase-dev@hadoop.apache.org Received: (qmail 81004 invoked by uid 99); 15 Apr 2010 06:13:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Apr 2010 06:13:55 +0000 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=AWL,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [209.85.210.192] (HELO mail-yx0-f192.google.com) (209.85.210.192) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Apr 2010 06:13:51 +0000 Received: by yxe30 with SMTP id 30so617136yxe.30 for ; Wed, 14 Apr 2010 23:13:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.197.96 with HTTP; Wed, 14 Apr 2010 23:13:09 -0700 (PDT) In-Reply-To: References: From: Todd Lipcon Date: Wed, 14 Apr 2010 23:13:09 -0700 Received: by 10.101.109.20 with SMTP id l20mr16735966anm.37.1271312009264; Wed, 14 Apr 2010 23:13:29 -0700 (PDT) Message-ID: Subject: Re: 0.20.4RC1? (WAS -> Re: Vote on 0.20.3.1) To: hbase-dev@hadoop.apache.org Content-Type: multipart/alternative; boundary=001636ed7394b600da048440647a --001636ed7394b600da048440647a Content-Type: text/plain; charset=ISO-8859-1 I'm cool with an rc, but what is our timeline for testing? Given we just committed 2248, which is a pretty huge change, I think we should let it soak for developers for at least a week or so before moving from rc to release? -Todd On Wed, Apr 14, 2010 at 9:42 PM, Stack wrote: > Unless objection, I was going to put up a 0.20.4 Release Candidate 1 > made from the tip of the 0.20_pre_durability branch tomorrow. > > Andrew, I was thinking you could level your ec2 guns at the RC or, > would you rather me wait and let you go at the tip of the branch > first? Just say. > > Anything else we need to get in before I cut the candidate? > Thanks, > St.Ack > > > On Wed, Apr 7, 2010 at 9:09 PM, Ryan Rawson wrote: > > I like this. With no durability goal, we should be able to hit this in > > short order. HDFS is not ready for the claim as of yet. > > > > > > > > On Wed, Apr 7, 2010 at 5:25 PM, Stack wrote: > >> I went through the list issues that we had filed against a 0.20.4. I > >> moved out the issues that depend on hdfs-200, post rpc-version change, > >> etc. Outstanding are ~15 issues: http://su.pr/1TLvb7 A good few are > >> patch available. A couple of others are small doc issues. I'll take > >> care of the easy ones this evening. Please go over the list > >> yourselves to see what else we should include. As is, the list > >> includes hbase-2248. I think we should try and get this one in if > >> only to make the release a little interesting (and to fix the > >> deadlock). We also need to fix the json jar issue so we have chance > >> of being debian package. > >> > >> St.Ack > >> P.S. I haven't voted yet. At the moment I'm +0. If hbase-2248 goes > >> in, I'd go +1. > >> > >> On Wed, Apr 7, 2010 at 3:40 PM, Andrew Purtell > wrote: > >>> Implied is we move people to 0.20.5 rather than do a patch on 0.20.4, > beyond the RC period. > >>> > >>> Hence it's even more important that J-D cherry pick bugfixes out of > 0.20.4-dev for an 0.20.4 RC and release. > >>> > >>> Is that acceptable? > >>> > >>> - Andy > >>> > >>> > >>>> From: Andrew Purtell > >>>> Subject: Re: Vote on 0.20.3.1 > >>>> To: "hbase-dev@hadoop.apache.org" > >>>> Date: Wednesday, April 7, 2010, 3:35 PM > >>>> > From: Jonathan Gray > >>>> > > >>>> > The issue would be that we break out 0.20.4 to make an > >>>> RC. > >>>> > Now we have to patch 3 separate trees for each bug fix > >>>> (0.20.4, > >>>> > 0.20.5, and 0.21). > >>>> > >>>> Ok, I grant you that. But only during the RC. > >>>> > >>>> - Andy > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >> > > > -- Todd Lipcon Software Engineer, Cloudera --001636ed7394b600da048440647a--