cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Date Wed, 03 Dec 2014 10:54:22 GMT
sounds good, we (@SBP) started working with reviews of the commit
diffs for master. Sounds like this is compliant with yours. I kind of
release branch 4.4 for this reason so under this condition it will
again become more workable/less effort to control the stuff.

On Wed, Dec 3, 2014 at 9:16 AM, Hugo Trippaers <> wrote:
> Will,
> Sounds good, i need to discuss with Daan, but i’m tempted to follow this convention
to see how it pans out.
> Cheers,
> Hugo
>> On 3 dec. 2014, at 00:44, Will Stevens <> wrote:
>> I just posted a topic called: [MERGE REQUEST] hotfix/4.5-7959
>> This is a workflow that I am going to adopt and test out for a little while
>> to see if it has real benefits.  I have added some notes below as to why I
>> decided to start doing this.  This came out of a lot of conversations at
>> I am going to adopt this approach for getting fixes merged into release
>> branches.  The 'hotfix' branch method that we adopted for 4.4 seems to work
>> very well, so I want to continue to use a similar technique.
>> In addition to the benefits that we got from the hotfix branches,
>> requesting a MERGE REQUEST also gives us the following benefits:
>> - If the branch's release manager wants to manage all of the commits they
>> can, but not every release manager wants to have to do every merge.  This
>> way a release manager can delegate some helpers who they trust to help them
>> merge in hotfixes.
>> - This seems to me like the cheapest (least overhead) way to implement some
>> basic peer review of commits.  Yes, I have access to commit directly to the
>> 4.5 branch, but that does not mean that I should.  This way we at least get
>> another committers approval before changes get merged.
>> - As a committer, it is my responsibility for creating a hotfix branch for
>> each of the releases my change fixes and test them.  This way me as the
>> developer who made the initial changes can make sure there will not be
>> merge conflicts in the other branches when I create my hotfix branches.
>> This will simplify the job for the release managers and will reduce the
>> need for cherry picking.  If I am asking for multiple hotfixes for the same
>> issue I could do the following; [MERGE REQUEST] hotfix/4.4-1234,
>> hotfix/4.5-1234  then the respective release managers or delegates can
>> merge the hotfixes and post back MERGED so there is a bit of a feedback
>> loop.
>> Anyway, this is a workflow I am going to adopt for changes to the release
>> branches and we will see if there are any issues with it.  If you have
>> ideas to improve this, please join the conversation...
>> Cheers,
>> *Will STEVENS*
>> Lead Developer
>> *CloudOps* *| *Cloud Solutions Experts
>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>> w *|* tw @CloudOps_


View raw message