bq. Should we revive [DISCUSS] thread on mobs? I think we should.
bq. when Andrew asked around who already uses mobs in trunk I saw that email. It was during Chinese New Year. Some people might have missed it. On Thu, Feb 25, 2016 at 3:21 PM, Mikhail Antonov <[email protected]> wrote: > Thanks Enis. > > If there're no objections, I'll open umbrella jira for release then. > > I went back and glanced at the discussions on mobs. Looks like last > time(s) there were these sorts of comments: > > - "How stable is it on master, is it stable enough to backport to > branch-1". > There was a comment that there was some sizable cleanup going on in > master, or some commented out/disabled tests? Are there any changes here? > What others think - how stable is it now in master? > - "Shouldn't we rather try to get 2.0 release out and have mobs there". - > So how far do we feel 2.0 release is? > - A question to dev@ and user@ groups - "are there actually folks > already > using it in trunk?" - that question got no replies as far as I can see. > Anyone can comment here? > > Should we revive [DISCUSS] thread on mobs? I think last time the ball was > dropped when Andrew asked around who already uses mobs in trunk, if I've > not missed something? > > I think as was noted before, backporting of spark connector should be less > risky as it's less intrusive. So I guess we're waiting on the progress > on HBASE-14160 here? > > -Mikhail > > On Thu, Feb 25, 2016 at 2:34 PM, Ted Yu <[email protected]> wrote: > > > I have linked HBASE-14801 to HBASE-14160 > > > > Thanks for the reminder. > > > > On Thu, Feb 25, 2016 at 2:30 PM, Sean Busbey <[email protected]> > wrote: > > > > > The jira tracking blockers for hbase-spark making it into branch-1 > > > is HBASE-14160. If HBASE-14801 is required, please make sure it is > > listed. > > > > > > On Thu, Feb 25, 2016 at 3:32 PM, Ted Yu <[email protected]> wrote: > > > > > > > There is also hbase-spark module worth considering for backport. > > > > > > > > Current active JIRA is HBASE-14801 > > > > > > > > FYI > > > > > > > > On Thu, Feb 25, 2016 at 1:25 PM, Enis Söztutar <[email protected]> > > > wrote: > > > > > > > > > Thanks Mikhail. Looks like a good enough list for justifying a > minor > > > > > release. > > > > > > > > > > HBASE-15181 is almost ready to go. > > > > > > > > > > What do you guys think about MOB in branch-1, and possibly in 1.3. > > > There > > > > > was a separate thread some time ago, don't remember the conclusion > > > there. > > > > > > > > > > Enis > > > > > > > > > > On Thu, Feb 25, 2016 at 12:54 PM, Mikhail Antonov < > > [email protected]> > > > > > wrote: > > > > > > > > > > > To me it's not really about individual big features (besides, big > > > > > features > > > > > > might be hard to accommodate in a minor release), but enough good > > > > things > > > > > to > > > > > > justify minor release. > > > > > > > > > > > > What we can have (unless I'm missing something): > > > > > > > > > > > > [Already done or to be further improved] > > > > > > - HBASE-15177 - more GC-friendly allocations in RPC services > > > > > > - HBASE-14457 - multi WAL improvements > > > > > > - HBASE-15222 - optimizations in metrics system, some more > metrics > > > > > > (like HBASE-15135, HBASE-15068) > > > > > > - HBASE-15306, HBASE-15136 - improving call queues handling > > > > > > > > > > > > [To be reviewed?): > > > > > > - HBASE-15181 - date based tiered compactions (?) > > > > > > - HBASE-11290 - unlock RegionStates. There was a patch update > > > > relatively > > > > > > recently to it based on comments. > > > > > > > > > > > > [Possible?] > > > > > > - HBASE-13557 - special handling for system tables WALs > > > > > > - HBASE-13017 - keep table state in meta > > > > > > > > > > > > 1.2 was cut off mid-June 2015.. Should be enough time since then > > for > > > a > > > > > > minor release. > > > > > > > > > > > > Mikhail > > > > > > > > > > > > On Thu, Feb 25, 2016 at 10:56 AM, Enis Söztutar < > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > What are the "features" in current branch-1 that is not there > in > > > 1.2? > > > > > If > > > > > > > there is none, it is not worth branching yet. > > > > > > > > > > > > > > Enis > > > > > > > > > > > > > > On Wed, Feb 24, 2016 at 7:57 PM, Andrew Purtell < > > > > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > No, each 0.94.x/0.96.x/98.x was or is a minor release. :-) > > > > Sometimes > > > > > > the > > > > > > > > changes in those releases could all be considered "point" in > > > scope > > > > or > > > > > > > > effect but not always. Further supporting this point of view, > > > when > > > > we > > > > > > > went > > > > > > > > from 0.94 to 0.96 it was a major increment, in effect, due to > > > 'the > > > > > > > > singularity'. > > > > > > > > > > > > > > > > Doing a new minor every month would be more like a return to > > past > > > > > state > > > > > > > of > > > > > > > > affairs, for better or worse, in my humble opinion. > > > > > > > > > > > > > > > > > On Feb 24, 2016, at 7:46 PM, Stack <[email protected]> > wrote: > > > > > > > > > > > > > > > > > >> On Wed, Feb 24, 2016 at 11:50 AM, Elliott Clark < > > > > > [email protected]> > > > > > > > > wrote: > > > > > > > > >> > > > > > > > > >> Is it time to branch for 1.3 ? > > > > > > > > > > > > > > > > > > > > > > > > > > >> Sean did a great job getting 1.2 out. However it was a > hard > > > > > > difficult > > > > > > > > >> process that I wouldn't wish on anyone. Is it time to > branch > > > for > > > > > 1.3 > > > > > > > and > > > > > > > > >> start the process of stabilizing again so that we can get > a > > > > > monthly > > > > > > > > cadence > > > > > > > > >> for minor releases going? > > > > > > > > > > > > > > > > > > > > > > > > > > > Monthly cadence for minors is upping the ante. We used to > be > > > > about > > > > > > > > > monthly's for point releases. > > > > > > > > > > > > > > > > > > +1 for the mighty Mikhail as RM. Sean, please UPS him the > > > special > > > > > > robe > > > > > > > > that > > > > > > > > > he has to wear while performing his RMness duties. > > > > > > > > > > > > > > > > > > St.Ack > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Sean > > > > > > > > > -- > Thanks, > Michael Antonov >
