hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@apache.org>
Subject Re: [VOTE] HBase 1.2.0 RC2
Date Fri, 12 Feb 2016 20:04:00 GMT
On Fri, Feb 12, 2016 at 11:44 AM, Sean Busbey <busbey@cloudera.com> wrote:

> I *could* make 1.2.0 RC3 that just cherry picks HBASE-15252 onto RC2, but
> that's going to make things a bit messy and possibly confusing for folks
> who look for the 1.2.0 tag to be an ancestor of branch-1.2's HEAD.
>

We have no strict requirement that a previous release is a git ancestor of
a later release. So long as the committed set of JIRAs matches, it's fine.
There's a precedent of this already with earlier 1.x release candidates.

On Fri, Feb 12, 2016 at 1:16 PM, Andrew Purtell <andrew.purtell@gmail.com>
> wrote:
>
> > Same here. I have started with RC2 but can mostly carry findings to RC3
> > given only one additional change.
> >
> > > On Feb 12, 2016, at 8:56 AM, Elliott Clark <eclark@apache.org> wrote:
> > >
> > > -1 until the dataloss is fixed.
> > >
> > > But assuming that's fixed I would be good for a short vote cycle for
> the
> > > next RC.
> > >
> > >> On Fri, Feb 12, 2016 at 1:02 AM, 张铎 <palomino219@gmail.com> wrote:
> > >>
> > >> HBASE-15252 is fixed :).
> > >>
> > >> 2016-02-12 14:00 GMT+08:00 Stack <stack@duboce.net>:
> > >>
> > >>> -1
> > >>>
> > >>> The dataloss issue was just discovered. I think now we know of it,
> even
> > >>> though the incidence is rare, would be best to respin the RC.
> > >>>
> > >>> You the man Sean,
> > >>> St.Ack
> > >>>
> > >>>
> > >>>> On Thu, Feb 11, 2016 at 8:59 PM, Stack <stack@duboce.net>
wrote:
> > >>>>
> > >>>> On Thu, Feb 11, 2016 at 5:04 PM, Sean Busbey <sean.busbey@gmail.com
> >
> > >>>> wrote:
> > >>>>
> > >>>>>> On Feb 11, 2016 18:33, "张铎" <palomino219@gmail.com>
wrote:
> > >>>>>>
> > >>>>>> Should we include HBASE-15252? It is a data loss issue.
> > >>>>>
> > >>>>> It's marked major (though perhaps that's off since it's dataloss,
> > even
> > >>> if
> > >>>>> rare). More importantly it's been present in prior releases
for
> some
> > >>> time.
> > >>>>>
> > >>>>> Blocking 1.2.0 would put pressure on getting a solution faster,
I
> > >> think.
> > >>>>> Additionally, letting the fix wait for 1.2.1 will give me a
good
> > >>> incentive
> > >>>>> to keep the path releases on schedule. ;)
> > >>>>>
> > >>>>> My 2¢. Happy to roll another RC if folks see it otherwise.
> > >>>>
> > >>>> Dataloss. I think we should roll a new RC with short voting
> timeframe.
> > >>>> St.Ack
> > >>
> >
>
>
>
> --
> Sean
>

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