From general-return-4016-apmail-hadoop-general-archive=hadoop.apache.org@hadoop.apache.org Mon Jul 11 21:42:18 2011 Return-Path: X-Original-To: apmail-hadoop-general-archive@minotaur.apache.org Delivered-To: apmail-hadoop-general-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id ED3CB4D30 for ; Mon, 11 Jul 2011 21:42:17 +0000 (UTC) Received: (qmail 93493 invoked by uid 500); 11 Jul 2011 21:42:16 -0000 Delivered-To: apmail-hadoop-general-archive@hadoop.apache.org Received: (qmail 93385 invoked by uid 500); 11 Jul 2011 21:42:15 -0000 Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@hadoop.apache.org Delivered-To: mailing list general@hadoop.apache.org Received: (qmail 93377 invoked by uid 99); 11 Jul 2011 21:42:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jul 2011 21:42:15 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of eli@cloudera.com designates 74.125.82.42 as permitted sender) Received: from [74.125.82.42] (HELO mail-ww0-f42.google.com) (74.125.82.42) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jul 2011 21:42:09 +0000 Received: by wwg11 with SMTP id 11so2794833wwg.5 for ; Mon, 11 Jul 2011 14:41:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.150.222 with SMTP id z72mr3446547wej.109.1310420508883; Mon, 11 Jul 2011 14:41:48 -0700 (PDT) Received: by 10.216.235.157 with HTTP; Mon, 11 Jul 2011 14:41:48 -0700 (PDT) In-Reply-To: References: <20967111-1229-4149-88D3-B4DEB8F49C64@hortonworks.com> Date: Mon, 11 Jul 2011 14:41:48 -0700 Message-ID: Subject: Re: HDFS-1623 branching strategy From: Eli Collins To: general@hadoop.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Jul 11, 2011 at 1:28 PM, Suresh Srinivas wrote: > Sorry for the late reply... > > My concern is not about creating a branch. Using a branch is some thing > we have been doing for a long time for feature development and it is > effective. Infact I am eager for branch for HA to be created, to start > submitting the patches I am currently working on. > > Here are some of my concerns: > Commit-then-review: > I have same concerns expressed by Jakob, about commit and review. My > preference is to review before commit. Reviewing incremental changes is much > more effective than reviewing one mega patch during merge of a branch. In CTR you still review individual changes, it just means you can do the review after the change was committed (and you address review feedback in a follow-on patch). I'm actually happy to do RTC, I prefer that as well. As long as each change is individually reviewed I'm fine either way. > From what I also know, HDFS-2064 HA is being planned for release 0.22. That's up to the 0.22 RM. It's not a blocker and it's unclear if we'll have a 0.22 release. > At an early glance, this seems to be closely tied to Backup node and not > generic enough (will post comments to jira). Given that this is added to > 0.22, > how does that impact the current HA plans and backward compatibility > requirements? I don't think the 1632 work needs to gate 2064, and vice versa. > Release 0.23: > Initial plan was to make HA part of post 0.23 (as discussed in contributors > meetup). It would be good to work in that direction and commit changes to > HDFS-1623 branch instead of making changes in the trunk, to ensure stability > of the trunk. HADOOP-7380 went into trunk. It would be better for such > changes > to go into HDFS-1623 branch. We should merge this branch post 0.23 into > trunk. Per the summit and previous discussion the current plan is still to get HA into a minor release of 0.23 right? Thanks, Eli