+1 on early branch, and count me in for the coming stability/perf projects (smile).
Best Regards, Yu On 31 March 2017 at 09:22, Enis Söztutar <e...@apache.org> wrote: > Thanks Stack for the update. +1 on branching as soon as possible. For > getting aforementioned stability, we need to start rejecting patches/ > features from 2.0.0. Branching early gives us the option of gradually > working towards that, but also does not block new development to happen on > master. I think the most important job for the RM is to say NO to > improvement jiras going into 2.0, if they have nothing to do with the > agreed upon goals of the release. > > Enis > > On Thu, Mar 30, 2017 at 5:07 PM, Stack <st...@duboce.net> wrote: > > > Some notes on progress toward hbase2. > > > > Given that stability and performance are NOT emergent behaviors but > rather > > projects unto themselves, my thought is that we commit all that we've > > agreed as core for hbase2 (see [1]), branch, and then work on stabilizing > > and perf rather than do stabilize, commit, and then branch. What this > means > > in practice is that for features like Inmemory Compaction, we commit it > > defaulted 'on' ("BASIC" mode) which is what we want in hbase2. Should it > > prove problematic under test, we disable it before release. > > > > Are folks good w/ this mode? I ask because, in a few issues there are > > requests for proof that a master feature is 'stable' before commit. This > is > > normally a healthy request only in master's case, it is hard to > demonstrate > > stability given its current state. > > > > Other outstanding issues such as decisions about whether master hosts > > system tables only (by default), I'm thinking, we can work out post > branch > > in alpha/betas before release. > > > > The awkward item is the long-pole Assignment Manager. This is an > > all-or-nothing affair. Here we are switching in a new Master core. While > I > > think it fine that AMv2 is incomplete come branch time, those of us > working > > on the new AM still need to demonstrate to you all that it basically > > viable. > > > > The point-of-no-return is commit of the patch in HBASE-14614. HBASE-14614 > > (AMv2) is coming close to passing all unit tests. We'll spend some time > > running it on a cluster to make sure it fundamentally sound and will > report > > back on our experience. There has been an ask for some dev doc and > > low-levels on how it works (in progress). Let satisfaction of these > > requests be blockers on commit. We'll put the HBASE-14614 commit up for a > > vote on dev list given its import. > > > > Branch will happen after HBASE-14614 goes in (or its rejection) with our > > first alpha soon after. Its looking like a week or two at least given how > > things have been going up to this. > > > > I intend to start in on hbase2 stability/perf projects after we branch. > > > > Interested in any thoughts you all might have on the above (Would also > > appreciate updates on state in [1] if you are a feature owner). > > > > Thanks, > > St.Ack > > > > 1. https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4 > > z9iEu_ktczrlKHK8N4SZzs/edit# > > > > > > > > On Sat, Mar 11, 2017 at 5:32 PM, Josh Elser <els...@apache.org> wrote: > > > > > > > > Stack wrote: > > > > > >> On Tue, Mar 7, 2017 at 1:51 PM, Josh Elser<els...@apache.org> wrote: > > >> > > >> Thanks for pulling in the FS Quotas work, Stack. I'm trying to cross > the > > >>> last T's and dot the last I's. > > >>> > > >>> The biggest thing I know I need to do still is to write a new chapter > > to > > >>> the book. After that, I'd start entertaining larger > reviews/discussions > > >>> to > > >>> merge the feature into master. Anyone with free time (giggles) is > more > > >>> than > > >>> welcome to start perusing :) > > >>> > > >>> > > >>> Out of interest, this could come in after 2.0 Josh? Any 2.0 specific > > >> needs > > >> to make this work? > > >> > > >> Meantime, updated the 2.0 doc 1. > > >> > > >> Thanks Josh, > > >> St.Ack > > >> > > >> 1. > > >> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9i > > >> Eu_ktczrlKHK8N4SZzs/edit# > > >> > > >> > > > Nope, no need to block 2.0 on this one (given the other, related > > chatter). > > > Would be nice to get it in, but I completely understand if it slips :) > > > > > > Thanks for updating the doc for me! > > > > > >