hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: [VOTE] Merge branch HBASE-10070 to trunk
Date Wed, 04 Jun 2014 17:48:39 GMT
I realize this is a vote thread but I need a satisfactory answer to the
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öztutar <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 which 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 sure
>>> 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 the same
>> on master.
>>
>>
>> On Mon, Jun 2, 2014 at 2:24 PM, Enis Söztutar <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 which 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 sure
>>> everything is ok.
>>>
>>> An overview of the changes, and the status of the work can be found under
>>> [4], [6] and [7].In summary, with the code in branch, you can create
>>> tables
>>> with region replicas, do gets / multi gets and scans using TIMELINE
>>> consistency with high availability. Region replicas periodically scan the
>>> files of the primary and pick up flushed / committed files. The RPC
>>> paths /
>>> assignment, balancing etc are pretty stable. However some more
>>> performance
>>> analysis and tuning is needed. Phase 2 work is being worked on under
>>> HBASE-11183, and we have some working prototype for async-replicating and
>>> region splits. However, we believe even without those features, this work
>>> is useable (especially for read-only/bulk load tables) , and can be
>>> 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 June, PDT.
>>>
>>> Here is my official +1.
>>>
>>> Thanks,
>>> Enis
>>>
>>> [1]
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=log;h=refs/heads/hbase-10070
>>> [2]
>>>
>>> https://issues.apache.org/jira/browse/HBASE-11214?jql=fixVersion%20%3D%20hbase-10070%20AND%20project%20%3D%20HBASE%20AND%20status%20%3D%20resolved
>>> [3]
>>>
>>> https://issues.apache.org/jira/browse/HBASE-10792?jql=fixVersion%20%3D%20hbase-10070%20and%20fixversion%20%3D%200.99.0%20AND%20project%20%3D%20HBASE%20AND%20status%20%3D%20resolved
>>> [4] https://www.mail-archive.com/dev@hbase.apache.org/msg25795.html
>>> [5]
>>>
>>> https://github.com/apache/hbase/commit/e22c7efeac02efde3451a0c9ff9bdcd2725576d0
>>> [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 Hein
(via Tom White)

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