hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Vote on 0.20.3.1
Date Wed, 07 Apr 2010 18:21:57 GMT
On Tue, Apr 6, 2010 at 10:24 PM, Ryan Rawson <ryanobjc@gmail.com> wrote:
> I don't get it - why did we commit all those things to 0.20 branch if
> they are not suitable for the next release?
>
> If we did accidentally commit things that are not suitable for 0.20.4,
> then we should revert them asap and make a 0.20.4 release from branch.
>  Branching your release branch is... not a good idea.
>

I don't see any issue with branching a release branch.

Regards 0.20.4, all in branch needs to make it into a release but the
proposed 0.20.4 is currently incomplete.  The suggestion is that
meantime, make a release that leaves out the half-done stuff --tested
data durability, etc. -- and ship critical bug fixes only.

My current dilemma is that I think a release should include HBASE-2322
"deadlock between put and cacheflusher in 0.20 branch" -- this seemed
easy for me to trigger bulk uploading and IMO, a blocker -- but the
fix for the deadlock is HBASE-2248 "Provide new non-copy mechanism to
assure atomic reads in get and scan", a critical fix but a big change
in how Gets work.  I'd like to ship with HBASE-2248 -- for one of the
reasons why, see comments in HBASE-2322 -- but I'd be uncomfortable
doing so w/o a bunch of testing first.

What do you all think?

St.Ack

Mime
View raw message