cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <>
Date Tue, 02 Dec 2014 23:44:59 GMT
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

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...


Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w *|* tw @CloudOps_

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message