hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject Re: Planning for HBase 1.2
Date Fri, 29 May 2015 19:28:47 GMT
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 <busbey@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 <larsh@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 <busbey@cloudera.com>
> > *To:* dev <dev@hbase.apache.org>; lars hofhansl <larsh@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 <larsh@apache.org>
> wrote:
> >
> > Agreed. I'd add that shipping a major feature like MOB with a minor
> branch
> > "feels" wrong.
> >       From: Andrew Purtell <apurtell@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 <apurtell@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 <busbey@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message