Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of yuzhihong@gmail.com
 designates 209.85.161.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADY20s4q-V4bmgUXMjMMv1j+vtf=JqOuAuX-H_n=_TrO4Yhg8g@mail.gmail.com>
References: 
 <CALte62yAyxqc7wtsn0HZyuTxhQSKuZpAaME2jSz9+D6vmdjKeg@mail.gmail.com>
	<CADY20s4q-V4bmgUXMjMMv1j+vtf=JqOuAuX-H_n=_TrO4Yhg8g@mail.gmail.com>
Date: Thu, 18 Aug 2011 17:53:32 -0700
Message-ID: 
 <CALte62z-5cy_8JY6B=T9nyWQUKCZQCWEb0tzA_Q1AXVMg3fB2w@mail.gmail.com>
Subject: Re: HBASE-1730 and HBASE-4213
From: Ted Yu <yuzhihong@gmail.com>
To: dev@hbase.apache.org
Cc: Subbu M Iyer <msiyer@gmail.com>, nileema.shingte@gmail.com
Content-Type: multipart/alternative; boundary=20cf303f6a348fcaa204aad12843

--20cf303f6a348fcaa204aad12843
Content-Type: text/plain; charset=ISO-8859-1

I prefer choice A below.

Let's vote on which implementation is the better approach.

My vote is for 4213. Subbu implemented hbase-451 and has deep understanding
of related code.
Using zookeeper to record transient state is Andy's favorite choice.

Cheers

On Thu, Aug 18, 2011 at 5:29 PM, Todd Lipcon <todd@cloudera.com> wrote:

> In my opinion we have three options:
>
> (a) have the two contributors work together on a single JIRA
> (b) factor out what's common between their approaches into a new JIRA,
> then let them proceed independently
> or (c) let them proceed independently, and whichever one reaches a
> suitable commitable state first, we go with
>
> If they both become committable around the same time, then we should
> go to benchmarks as well as comparisons of which codebase seems more
> maintainable.
>
> -Todd
>
> On Thu, Aug 18, 2011 at 4:23 PM, Ted Yu <yuzhihong@gmail.com> wrote:
> > Hi,
> > Due to lack of coordination, HBASE-1730 and HBASE-4213 try to implement
> the
> > same feature at roughly the same pace.
> >
> > I want to hear your opinion on how we should plan to move forward with
> these
> > two JIRAs.
> > One possibility is to provide two policies, one accommodating each JIRA.
> But
> > that requires even more work.
> >
> > It would be nice if we can have some performance numbers for both
> > implementations on comparable cluster(s).
> >
> > Cheers
> >
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

--20cf303f6a348fcaa204aad12843--