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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> > wrote:
> >
> >>
> >> On Mon, Jun 2, 2014 at 2:24 PM, Enis Söztutar <[email protected]> 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 <[email protected]> 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/[email protected]/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)
>
