nch-2 back to branch-2.
>> > > > >>
>> > > > >> 2018-01-10 9:20 GMT+08:00 张铎(Duo Zhang) :
>> > > > >>
>> > > > >> If branch-2.0 will be out soon then let's target this to 2.1. No
>> > > >
> > >
> > > > >>>> wrote:
> > > > >>>>
> > > > >>>> OK, let me merge it master first. And then create a
> > > > HBASE-19397-branch-2
> > > > >>>>> which will keep
> >>>>> stable
> > > >>>>> enough. Since we can define this as a bug fix/refactoring rather
> > > than a
> > > >>>>>
> > > >>>> big
> > > >>>>
> > > >>>>> new
e hbase2.0, branch-2 will
become
hbase2.1...).
St.Ack
Thanks all here.
2018-01-09 12:06 GMT+08:00 ashish singhi :
+1 to merge on master and 2.1.
Great work.
Thanks,
Ashish
-Original Message-
From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
Sent: Tuesday, January 09, 2018
integrate it at any time. If we think it
> is
> > >>>>>
> > >>>> stable
> > >>>>
> > >>>>> enough before cutting branch-2.0 then we can include it in the
> 2.0.0
> > >>&g
lse let's include it in 2.1(Maybe we can backport it to 2.0
> >>>>> later?).
> >>>>>
> >>>>>
> >>>>>
> >>>> I need to cut the Appy-suggested branch-2.0. Shout if
> >>>> HBASE-19397-branch-2
> >>>> gets
h-2.0. Shout if
>>>> HBASE-19397-branch-2
>>>> gets to be too much work and I'll do it sooner rather than later. Or, if
>>>> easier on you, just say and I'll make the branch-2.0 now so you can just
>>>> commit to branch-2 (branch-2.0 will become hbase2.0, bran
l.com]
Sent: Tuesday, January 09, 2018 6:53 AM
To: dev@hbase.apache.org
Subject: Re: [VOTE] Merge branch HBASE-19397 back to master and
branch-2.
Anyway, if no objections on merging this into master, let's do it? So
that
we can start working on the follow-on features, such as table based
rep
say and I'll make the branch-2.0 now so you can
> just
> > >> commit to branch-2 (branch-2.0 will become hbase2.0, branch-2 will
> > become
> > >> hbase2.1...).
> > >>
> > >> St.Ack
> > >>
> > >>
> > >>
> &
> Thanks all here.
> >> >
> >> > 2018-01-09 12:06 GMT+08:00 ashish singhi :
> >> >
> >> > > +1 to merge on master and 2.1.
> >> > > Great work.
> >> > >
> >> > > Thanks,
> >> > > Ashish
>
t;> commit to branch-2 (branch-2.0 will become hbase2.0, branch-2 will
> become
> >> hbase2.1...).
> >>
> >> St.Ack
> >>
> >>
> >>
> >>
> >> > Thanks all here.
> >> >
> >> > 2018-01-09 12:06 GM
8-01-09 12:06 GMT+08:00 ashish singhi :
>> >
>> > > +1 to merge on master and 2.1.
>> > > Great work.
>> > >
>> > > Thanks,
>> > > Ashish
>> > >
>> > > -Original Message-
>> > > From: 张铎(Duo Zhan
GMT+08:00 ashish singhi :
> >
> > > +1 to merge on master and 2.1.
> > > Great work.
> > >
> > > Thanks,
> > > Ashish
> > >
> > > -Original Message-
> > > From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
> > &g
l here.
>
> 2018-01-09 12:06 GMT+08:00 ashish singhi :
>
> > +1 to merge on master and 2.1.
> > Great work.
> >
> > Thanks,
> > Ashish
> >
> > -Original Message-
> > From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
> > Sent: Tue
+1 on merging to master branch.
On Tue, Jan 9, 2018 at 6:51 AM, Josh Elser wrote:
> +1 on merge to Master.
>
> I appreciate the details you shared, Duo, but I think I'm still -0 on a
> branch-2 merge at this point. I'm with Stack: would rather pull it into a
> fast 2.1 release.
>
>
> On 1/8/18 8
+1 on merge to Master.
I appreciate the details you shared, Duo, but I think I'm still -0 on a
branch-2 merge at this point. I'm with Stack: would rather pull it into
a fast 2.1 release.
On 1/8/18 8:22 PM, 张铎(Duo Zhang) wrote:
Anyway, if no objections on merging this into master, let's do it
sh
>
> -Original Message-
> From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
> Sent: Tuesday, January 09, 2018 6:53 AM
> To: dev@hbase.apache.org
> Subject: Re: [VOTE] Merge branch HBASE-19397 back to master and branch-2.
>
> Anyway, if no objections on merging thi
+1 to merge on master and 2.1.
Great work.
Thanks,
Ashish
-Original Message-
From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
Sent: Tuesday, January 09, 2018 6:53 AM
To: dev@hbase.apache.org
Subject: Re: [VOTE] Merge branch HBASE-19397 back to master and branch-2.
Anyway, if no
> For the replication peer tracking, it is the same problem. It is hard to
do
> fencing with zk watcher since it is asynchronous, so the UTs are always
> kind of flakey in theoretical.
> the synchronous guarantee is really a good thing for our replication
related UTs.
> And we have also done a ha
On Mon, Jan 8, 2018 at 5:22 PM, 张铎(Duo Zhang) wrote:
> Anyway, if no objections on merging this into master, let's do it? So that
> we can start working on the follow-on features, such as table based
> replication storage, and synchronous replication, etc.
>
>
+1 for Master.
> > You see it as
+1 for both master and branch-2. IMHO flaky UT designs are some must-fix
once found, efforts will be paid sooner or later in stability testing (or
in production after release if our svt coverage is not good enough).
Best Regards,
Yu
On 9 January 2018 at 10:32, OpenInx wrote:
> +1 for a merge t
+1 for a merge to master firstly ( no-binding )
If merge into the master branch as early as possible, we can develop
follow-on features (table based features & sync-replication) as early as
possible.
On Tue, Jan 9, 2018 at 9:28 AM, Andrew Purtell wrote:
> FWIW, you have my +1 for a merge to ma
FWIW, you have my +1 for a merge to master.
On Mon, Jan 8, 2018 at 5:22 PM, 张铎(Duo Zhang) wrote:
> Anyway, if no objections on merging this into master, let's do it? So that
> we can start working on the follow-on features, such as table based
> replication storage, and synchronous replication
Anyway, if no objections on merging this into master, let's do it? So that
we can start working on the follow-on features, such as table based
replication storage, and synchronous replication, etc.
Thanks.
2018-01-09 7:19 GMT+08:00 Stack :
> On Mon, Jan 8, 2018 at 2:50 PM, 张铎(Duo Zhang)
> wrote
On Mon, Jan 8, 2018 at 2:50 PM, 张铎(Duo Zhang) wrote:
> This 'new' feature only changes DDL part, not the core part of replication,
> i.e, how to read wal entries and how to replicate it to the remote cluster,
> etc. And also there is no pb message/storage layout change, you can think
> of this as
This 'new' feature only changes DDL part, not the core part of replication,
i.e, how to read wal entries and how to replicate it to the remote cluster,
etc. And also there is no pb message/storage layout change, you can think
of this as a big refactoring. Theoretically we even do not need to add ne
Same questions as Josh's.
1) We have RCs for beta1 now, which means only commits that can go in are
bug fixes only. This change - although important, needed from long time and
well done (testing, summary, etc) - seems rather very large to get into 2.0
now. Needs good justification why it has to be
-0 From a general project planning point-of-view (not based on the
technical merit of the code) I am uncomfortable about pulling in a brand
new feature after we've already made one beta RC.
Duo -- can you expand on why this feature is so important that we should
break our release plan? Are the
Here is my +1.
Executed the test suites several times,
with -Dsurefire.secondPartForkCount=1, and also the exclusion of flakey
tests(including TestFromClientSide) I could get a successful build.
Started two clusters with the code of the latest HBASE-19397, tried adding
a new peer, it worked fine.
29 matches
Mail list logo
