Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of ddas@hortonworks.com designates
 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+RK=_B7LX_vNjOmyqHH0-dfXYGvcNxuSX4SM5Z_taDp0iN+Eg@mail.gmail.com>
References: 
 <CAMUu0w8uvb29+QYpZ8VwSO4qEpKRyKGNPzyj1kw7tLRhLPoZkA@mail.gmail.com>
	<CA+RK=_CWMv-kfw2jxM3BB-X2dsa_P8DqA6kB9ei_V0m4TQFOaA@mail.gmail.com>
	<CA+RK=_D17-n3WF4SsG+jA_V_RqSjDzBQ-p3tL+vevkHZ2AeMmw@mail.gmail.com>
	<CA+RK=_APH9dkkwsAF0oV19kdaYC5Jd7+BVBnB0mG=VVnJiZb=g@mail.gmail.com>
	<CAMUu0w9bYbb1=rzUXqznsz3wq7HELCwOuXhQtOz4fG_HAGAQ4A@mail.gmail.com>
	<CA+RK=_B7LX_vNjOmyqHH0-dfXYGvcNxuSX4SM5Z_taDp0iN+Eg@mail.gmail.com>
Date: Fri, 6 Jun 2014 14:42:20 -0700
Message-ID: 
 <CAPzbcGTJtGgmGUntVmxgM2+WLJUAHgsu5p65kWsyQxQF8OsrqQ@mail.gmail.com>
Subject: Re: [VOTE] Merge branch HBASE-10070 to trunk
From: Devaraj Das <ddas@hortonworks.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1

On Fri, Jun 6, 2014 at 2:13 PM, Andrew Purtell <apurtell@apache.org> wrote:
> +1, thanks Enis
>
>
> On Fri, Jun 6, 2014 at 1:46 PM, Enis S=C3=B6ztutar <enis.soz@gmail.com> w=
rote:
>
>> Sorry, I was mostly out for HadoopSummit.
>>
>> Yes, the git flow would be very similar to what you propose:
>>
>>      $ git checkout HBASE-10070
>>      $ git rebase --ignore-date master
>>      (fixups, git add, git rebase --continue, etc, etc, etc)
>>      $ git checkout master
>>
>>      $ git push origin HBASE-10070 HBASE-10070-rebase-date   (optionally=
)
>>      $ git merge HBASE-10070
>>
>> We can either go --ignore-date or not depending on what we want. If need=
ed
>> I am fine with pushing the rebased master branch for review to main repo
>> before the merge to another branch. If not, I can just rebase the branch
>> locally and merge + push to main repo.
>>
>> Creating final patches and attaching them to jira might be cumbersome. I=
f
>> we do the rebased-branch on repo, we might not need it. But if we need t=
hat
>> for review, I can do it.
>>
>> Thanks,
>> Enis
>>
>>
>>
>> On Wed, Jun 4, 2014 at 10:48 AM, Andrew Purtell <apurtell@apache.org>
>> wrote:
>>
>> > I realize this is a vote thread but I need a satisfactory answer to th=
e
>> > below inquiries before feeling comfortable casting a vote. Or perhaps
>> that
>> > means we need to cancel this vote and move back to discussion.
>> >
>> >
>> > On Tue, Jun 3, 2014 at 11:17 AM, Andrew Purtell <apurtell@apache.org>
>> > wrote:
>> >
>> > > Also after the merge process is completed, do you plan to use git
>> > > format-patch to break out the per-JIRA changes into updated patches =
for
>> > > those JIRAs representing in effect the final commit?
>> > >
>> > >
>> > > On Tue, Jun 3, 2014 at 11:16 AM, Andrew Purtell <apurtell@apache.org=
>
>> > > wrote:
>> > >
>> > >>
>> > >> On Mon, Jun 2, 2014 at 2:24 PM, Enis S=C3=B6ztutar <enis@apache.org=
>
>> wrote:
>> > >>
>> > >> This VOTE is for merging back the remaining changes in branch to
>> trunk.
>> > If
>> > >>> passes, we will rebase the branch on top of current trunk, in whic=
h
>> we
>> > >>> will
>> > >>> keep the commit-per-issue log history. After that we will do a git
>> > merge
>> > >>> for the branch keeping the history clean and not squashing the
>> > commits. I
>> > >>> expect rebasing to be straightforward, however with some manual
>> > conflict
>> > >>> resolution. After the merge we'll keep running the tests to make s=
ure
>> > >>> everything is ok.
>> > >>>
>> > >>
>> > >> Just to clarify that would look something like this:
>> > >>
>> > >>      $ git checkout HBASE-10070
>> > >>      $ git rebase --ignore-date master
>> > >>      (fixups, git add, git rebase --continue, etc, etc, etc)
>> > >>      $ git checkout master
>> > >>      $ git merge HBASE-10070
>> > >>
>> > >> ?
>> > >>
>> > >> That sounds good to me, the final merge should be a fast forward
>> merge.
>> > >>
>> > >> Use of ' --ignore-date' could be mildly controversial. It's not
>> strictly
>> > >> necessary because the commits for 10070 will appear grouped in
>> history,
>> > but
>> > >> then dates on commits will be discontiguous in that section of
>> history.
>> > I
>> > >> suggest using that option so the order of commits and dates sort th=
e
>> > same
>> > >> on master.
>> > >>
>> > >>
>> > >> On Mon, Jun 2, 2014 at 2:24 PM, Enis S=C3=B6ztutar <enis@apache.org=
>
>> wrote:
>> > >>
>> > >>> Hi,
>> > >>>
>> > >>> Last week we started some discussion[4] for merging branch
>> > hbase-10070[1]
>> > >>> into trunk. It seems like the consensus there is to do the merge
>> sooner
>> > >>> rather than later.
>> > >>>
>> > >>>
>> > >>> We had branched hbase-10070 in Feb out of trunk[5]. The branch
>> contains
>> > >>> 55
>> > >>> jiras committed[2]. Out of these 55, 15 has already been committed=
 to
>> > >>> trunk
>> > >>> and backported to hbase-10070 branch[3].
>> > >>>
>> > >>> This VOTE is for merging back the remaining changes in branch to
>> trunk.
>> > >>> If
>> > >>> passes, we will rebase the branch on top of current trunk, in whic=
h
>> we
>> > >>> will
>> > >>> keep the commit-per-issue log history. After that we will do a git
>> > merge
>> > >>> for the branch keeping the history clean and not squashing the
>> > commits. I
>> > >>> expect rebasing to be straightforward, however with some manual
>> > conflict
>> > >>> resolution. After the merge we'll keep running the tests to make s=
ure
>> > >>> everything is ok.
>> > >>>
>> > >>> An overview of the changes, and the status of the work can be foun=
d
>> > under
>> > >>> [4], [6] and [7].In summary, with the code in branch, you can crea=
te
>> > >>> tables
>> > >>> with region replicas, do gets / multi gets and scans using TIMELIN=
E
>> > >>> consistency with high availability. Region replicas periodically s=
can
>> > the
>> > >>> files of the primary and pick up flushed / committed files. The RP=
C
>> > >>> paths /
>> > >>> assignment, balancing etc are pretty stable. However some more
>> > >>> performance
>> > >>> analysis and tuning is needed. Phase 2 work is being worked on und=
er
>> > >>> HBASE-11183, and we have some working prototype for async-replicat=
ing
>> > and
>> > >>> region splits. However, we believe even without those features, th=
is
>> > work
>> > >>> is useable (especially for read-only/bulk load tables) , and can b=
e
>> > >>> released as an experimental feature in 1.0.
>> > >>>
>> > >>> Please indicate your choice:
>> > >>>
>> > >>> [ ] +1 on yes, merge branch hbase-10070 to trunk.
>> > >>> [ ] 0 on don't care
>> > >>> [ ] -1 don't merge, because ...
>> > >>>
>> > >>> I'll keep the vote running for 7 days, and close it Mon 9th of Jun=
e,
>> > PDT.
>> > >>>
>> > >>> Here is my official +1.
>> > >>>
>> > >>> Thanks,
>> > >>> Enis
>> > >>>
>> > >>> [1]
>> > >>>
>> > >>>
>> >
>> https://git-wip-us.apache.org/repos/asf?p=3Dhbase.git;a=3Dlog;h=3Drefs/h=
eads/hbase-10070
>> > >>> [2]
>> > >>>
>> > >>>
>> >
>> https://issues.apache.org/jira/browse/HBASE-11214?jql=3DfixVersion%20%3D=
%20hbase-10070%20AND%20project%20%3D%20HBASE%20AND%20status%20%3D%20resolve=
d
>> > >>> [3]
>> > >>>
>> > >>>
>> >
>> https://issues.apache.org/jira/browse/HBASE-10792?jql=3DfixVersion%20%3D=
%20hbase-10070%20and%20fixversion%20%3D%200.99.0%20AND%20project%20%3D%20HB=
ASE%20AND%20status%20%3D%20resolved
>> > >>> [4] https://www.mail-archive.com/dev@hbase.apache.org/msg25795.htm=
l
>> > >>> [5]
>> > >>>
>> > >>>
>> >
>> https://github.com/apache/hbase/commit/e22c7efeac02efde3451a0c9ff9bdcd27=
25576d0
>> > >>> [6]
>> > >>>
>> > >>>
>> >
>> http://www.slideshare.net/enissoz/hbase-high-availability-for-reads-with=
-time
>> > >>> [7] https://issues.apache.org/jira/browse/HBASE-10070
>> > >>>
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> 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)
>> > >
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> >    - Andy
>> >
>> > Problems worthy of attack prove their worth by hitting back. - Piet He=
in
>> > (via Tom White)
>> >
>>
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)

--=20
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to=
=20
which it is addressed and may contain information that is confidential,=20
privileged and exempt from disclosure under applicable law. If the reader=
=20
of this message is not the intended recipient, you are hereby notified that=
=20
any printing, copying, dissemination, distribution, disclosure or=20
forwarding of this communication is strictly prohibited. If you have=20
received this communication in error, please contact the sender immediately=
=20
and delete it from your system. Thank You.