+1 for Sean to be RM from me too. On Fri, May 29, 2015 at 12:28 PM, Enis Söztutar <e...@apache.org> wrote:
> 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 > > >
