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 <h...@apache.org> 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 <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_ > -- Daan
