Belated +1 for Sean for the 1.2 RM. It will be good for having diversity for RMs.
Enis On Fri, May 29, 2015 at 7:59 AM, Sean Busbey <bus...@cloudera.com> wrote: > 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 >
