Pardon me, what about this option: "I am fine with pushing the rebased master branch for review to main repo before the merge to another branch." Is the +1 for this -- I wouldn't mind having this option -- or for merge into master? St.Ack
On Fri, Jun 6, 2014 at 1:46 PM, Enis Söztutar <enis....@gmail.com> wrote: > 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 needed > 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. If > we do the rebased-branch on repo, we might not need it. But if we need that > for review, I can do it. > > Thanks, > Enis > > > > On Wed, Jun 4, 2014 at 10:48 AM, Andrew Purtell <apurt...@apache.org> > wrote: > > > 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 <apurt...@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 <apurt...@apache.org> > > > wrote: > > > > > >> > > >> On Mon, Jun 2, 2014 at 2:24 PM, Enis Söztutar <e...@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 <e...@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) > > >
