hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Planning for HBase 1.2
Date Fri, 29 May 2015 19:33:10 GMT
+1 for Sean to be RM from me too.

On Fri, May 29, 2015 at 12:28 PM, Enis Söztutar <enis@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 <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