incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
Subject Re: asf/vpc branch merge
Date Sat, 11 Aug 2012 20:18:46 GMT


On 08/10/2012 10:19 PM, Alena Prokharchyk wrote:
> As I'm not a git expert, I would appreciate any help from the community in
> figuring out what is the best way to merge vpc branch into master.
>
>
> Couple of ways I can think of:
>
> 1) git checkout master; git merge -s recursive -Xignore-space-change vpc
>
> Puts all commits from the vpc that are differnt from master, to the master
> branch.
>
> Pros:
>
> * no tree rebase happens
> * easier to revert individual commits if they cause any issues
> * Have 0 conflicts after the merge is done (just tested on my local branch)
> * Very close to vpc branch, so reduces the chances for regression bugs
> (vpc branch was tested)
>
>
> Cons:
>
> * harder to track down all VPC commits as they've been happening for a
> couple of months, and appear in the git log on the date they were
> originally submitted.
>
>
>
> 2) Do interactive rebase on master from vpc and squash all the commits
> into one
>

Have you thought about rebasing the vpc branch against master?

$ git checkout vpc
$ git rebase master
$ git checkout master
$ git merge vpc

It will then come in as one clean commit if you squash it all during 
your vpc rebase.

I did that with RBD to make it one nice commit which could be reverted 
if any issues would occur.

Wido

> git checkout master; git rebase -i asf/vpc
>
> Pros:
>
> * Easier to see all VPC changes as they come as a part of a single commit
>
> Cons:
>
> * Requires rebase which leads to lots of conflicts.
> * Not sure if there is an option to revert an individual commit happened
> as a part of squashed commit.
>
>
> I personally prefer way 1) as it doesn't lead to conflicts + leaves less
> chances for regression bugs as the asf/master structure becomes very
> similar to the structure of asf/vpc branch, and this branch was tested.
> But let me know if anybody sees any downsides of doing the merge this way
> and can suggest a better way.
>
>
> Thank you,
> -Alena.
>
>
>
> On 8/10/12 10:33 AM, "Alena Prokharchyk" <Alena.Prokharchyk@citrix.com>
> wrote:
>
>>
>> Considering that there is a code freeze happening soon, and as the main
>> part for VPC feature development is complete + the VPC code
>> has been well tested by cloudStack QA engineers, it's time to discuss
>> merging the asf/vpc branch into asf/master. At this point its too hard to
>> break it to several components-to-merge as there were too many single
>> commits for the last couple of months from 7 developers involved in the
>> process + we were doing the daily merges with master branch in order to
>> keep asf/vpc branch up to date. It makes it hard to componentize at this
>> point without running into lots of rebase conflicts
>>
>> So most likely it will be done as a single merge if
>> the merge gets approved by the community. We would highly
>> appreciate any help involving code/documentation review as well as any
>> other suggestions on how to make this particular merge safer and smoother.
>> And the suggestions made towards the merge process in general, will all be
>> addressed in the future.
>>
>> We've tried to keep vpc branch in sync with asf/master by performing daily
>> merges from master branch to vpc, so there shouldn't be too many
>> conflicts. The VPC code went through several rounds of QA including the
>> regression testing for existing network components. Most of the VPC code
>> resides in the new classes added as a part of the feature; but some
>> existing Network related code got some changes and can be considered for
>> the review (NetworkManagerImpl/VirtualNetworkApplianceManager in
>> particular as well as some Agent APIs and cloudStack UI). The VPC FS
>> contains the reference to new classes (including client/agent APIs)
>> created for the VPC feature (see the link below).
>>
>>
>> Functional specification:
>>
>> http://wiki.cloudstack.org/display/RelOps/Inter-VLAN+Routing+functional+sp
>> e
>> c
>>
>>
>> Engineer participated in VPC development:
>>
>> Sheng Yang - S2SVPN implementation
>> Alena Prokharchyk - Client/Agent APIs,
>> VpcManager/VpcVirtualNetworkApplianceManager/NetworkACLManager
>> Anthony Xu - All VirtualRuter script changes + feature implementation for
>> Xen resource
>> Kelven Yang - Implementation for VmWare resource
>> Sonny Chhan/Jessica Wang/Brian Federle - UI component
>>
>>
>> QA test cases execution matrix:
>>
>> http://wiki.cloudstack.org/display/QA/Inter-VLAN+Test+Execution
>>
>>
>> I'm well aware the 4.0 will be branched on Monday, so once the merge is
>> approved, I can do the merge over the weekend including doing basic
>> regression for the networking key components on the merged branch.
>>
>>
>> -Alena.
>>
>>
>
>

Mime
View raw message