This is my thinking, as well. In theory, 4.4-forward should be a superset of 4.4.
I don't think merging is required. On Mon, Jul 28, 2014 at 7:28 PM, Sheng Yang <sh...@yasker.org> wrote: > Daan, > > 4.4-forward should contain all the commits for 4.4. So 4.4-forward itself > should be able to make as 4.4, without merge back to 4.4? > > That's what we want to have a 4.4-forward for 4.4. future release. It's > superset of current 4.4 branch. > > Well, probably result in a force-overwrite. But I guess how we did it in > 4.3? Animesh? > > --Sheng > > > On Mon, Jul 28, 2014 at 2:36 AM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: > > > H, > > > > I tried merging 4.4-forward back into 4.4. This leaves us with a grand > > big conflict. I have calculated that the number of not cherry-picked > > not reverted commits is 185. I will start cherry-picking them at > > moments $dayjob allows. and then send a mail again. > > > > don't forget to read up on the proces git-flow is based upon. We will > > need to start working with a branch-merge per fix instead cherry-picks > > in the very near future. > > > > kind regards, > > -- > > Daan > > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
