You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Will Stevens <ws...@cloudops.com> on 2014/12/03 00:44:59 UTC
[DISCUSS] "MERGE REQUEST"
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_
Re: [DISCUSS] "MERGE REQUEST"
Posted by Rohit Yadav <ro...@shapeblue.com>.
Good idea Will,
I've few more additions;
- Don't merge bugfix to master (unless it's fixing a build etc.)
- Do reviews on Github PR, test using Travis and/or Jenkins.
- When the bugfix branch is good enough to be accepted on 4.5 (or
previous branches), merge those branch to the forward branches, i.e
merge 4.5 on master etc. This way master will get those commits as well
(this is something that Rajani has been doing lately to ensure we don't
lose any commit).
On Wednesday 03 December 2014 01:46 PM, 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 <ws...@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_
>
--
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 8826230892 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] "MERGE REQUEST"
Posted by Daan Hoogland <da...@gmail.com>.
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 <hu...@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 <ws...@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
Re: [DISCUSS] "MERGE REQUEST"
Posted by Hugo Trippaers <hu...@apache.org>.
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 <ws...@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_