On Thu, Mar 30, 2017 at 6:22 PM, 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.
>
>
Agreed (I've been practicing with a mirror).
And thanks Yu Li for volunteering to help with stability (a few others have
expressed interest too).
St.Ack
> 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!
> > >
> >
>
