It sounds like we have plenty to get into a 1.2 release regardless of how the discussion over MOB goes.
It sounds like we're at consensus for me taking on release manager for the 1.2 line? Presuming that's the case, I'll plan to cut a branch in mid-June with a goal of getting our first release candidate ready at the start of July. In general, for inclusion in the 1.2 release I'd like to ensure features we include can meet a common standard. * ITBLL passes with feature off and on under duress * ACID checks pass with feature off and on under duress * Some kind of verification that we don't backslide on security features * Feature docs in ref guide, presuming it is user facing at all * Operability tools to handle correctness checks and recovery * Perf analysis with feature off and on for both intended workloads and baseline Presuming the above points are handled, I'd be comfortable including features even if we currently want them labeled "experimental". Does this sound reasonable as a general gate for branch-1? Is there anything else we should be insisting on? On Sat, May 23, 2015 at 4:57 PM, lars hofhansl <la...@apache.org> wrote: > It's a large new feature. We might not technically break anything, but > we're introducing a lot of extra risk. > As a case in point... At Salesforce we think the timing would work out to > make 1.2 our next standard version. If MOBs were merged we'd likely stick > with 1.1 instead. > > I guess it all depends how long we're planning to maintain branches. If > 1.2 indicates the soon death of 1.1 we need to be more careful in 1.2. If > we're planning to keep 1.1 (and 1.0) around as long as 0.98, we can be more > aggressive. > > It's a fluffy discussion :) > > -- Lars > > ------------------------------ > *From:* Sean Busbey <bus...@cloudera.com> > *To:* dev <dev@hbase.apache.org>; lars hofhansl <la...@apache.org> > *Sent:* Friday, May 22, 2015 9:45 PM > > *Subject:* Re: Planning for HBase 1.2 > > So long as we can do it without breaking compatibility, what feels wrong > about it? If our goal is to get to semver, we have to progress to > descriptive numbers at some point. > > > > On Fri, May 22, 2015 at 11:39 PM, lars hofhansl <la...@apache.org> wrote: > > Agreed. I'd add that shipping a major feature like MOB with a minor branch > "feels" wrong. > From: Andrew Purtell <apurt...@apache.org> > To: "dev@hbase.apache.org" <dev@hbase.apache.org> > Sent: Friday, May 22, 2015 12:40 PM > Subject: Re: Planning for HBase 1.2 > > Another point of clarification, sorry, I hit the send button too early it > seems: I don't believe MOB is fully integrated yet, for example the feature > is an extension to store that lacks support for encryption (this would > technically be a feature regression); and HBCK. I have not been following > MOB too closely so could be mistaken. These issues do not preclude a merge > of MOB into trunk, but do preclude a merge back of MOB from trunk to > branch-1. I would veto the latter until such shortcomings in the > implementation that could be described as regressions are addressed. I > would also like to see a performance analysis of a range of workloads > before and after in as much detail as can be mustered, and would be happy > to volunteer to help out with that. > > > On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <apurt...@apache.org> > wrote: > > > I was also thinking about RMing for 1.2 as we try and bring something > post > > 1.0 into production at my employer. > > > > Related, of the list of features proposed I would strongly prefer MOB not > > be included. > > > > > > > > On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bus...@cloudera.com> > wrote: > > > >> Hi folks! > >> > >> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July. > >> > >> Here's an initial list of things I want to get out: > >> > >> * MOB > >> > >> * native crc > >> > >> * incremental improvements for procedure v2 > >> > >> * adding Java 8 as supported > >> > >> > >> Anything else folks want to see called out? > >> > >> -- > >> Sean > >> > > > > > > > > -- > > Best regards, > > > > - Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > (via Tom White) > > > > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) > > > > > > > > -- > Sean > > > -- Sean
