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 <wstev...@cloudops.com> 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 > CCCEU. > > 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 cloudops.com *|* tw @CloudOps_
