You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Daan Hoogland <da...@gmail.com> on 2014/08/08 09:46:36 UTC
must read
thanks Rohit,
I had missed this one. It contains obligatory release management
knowledge for every keyboard toucher that is allowed to use git:
https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
I think if we all read this and then study a bit we don't need to
discuss or branching model. It will become clear that we are in fact
doing almost fine and need only small changes.
--
Daan
Re: must read
Posted by Daan Hoogland <da...@gmail.com>.
On Fri, Aug 8, 2014 at 12:27 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hi Daan,
>
> On 08-Aug-2014, at 12:05 pm, Daan Hoogland <da...@gmail.com> wrote:
>
>> Rohit,
>>
>> A remark and a question:
...
>> Why insist on fast-forward? (In the git-flow document it is emphasised
>> that --no-ff should be used at all times)
>
> So, in my proposal I ask developers to merge release (or stable) branches to master (or develop/feature branch) often (say couple of times in the day), using --no-ff will generate a merge commit every time we do that. With fast-forward we’ll get linear history so that’s why I keep insisting on it.
>
> IMO We should only use --no-ff only when we want to have git to track the merge history (i.e. for someone to go and see what feature/branch got merged and what work was done in that merge branch).
Right, I just committed two fixes that are now just commits on 4.4 and
would have shown with merge commits, proving I eat my own dogfood. I
must say I am really not sure what I prefer. Leo showed me another
example of the difference where a merge was done on a branch that had
grown since the branch-off. Let's define carefully what we need when.
Not everybody is going to be savvy on this within the community and a
clear "do this, don't do that" might save the day.
A linear history is maybe good for little fixes/hotfixes but for
bigger features you do want the merge commit so you see clearly the
sideway that was created during the implementation.
ok?
Re: must read
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi Daan,
On 08-Aug-2014, at 12:05 pm, Daan Hoogland <da...@gmail.com> wrote:
> Rohit,
>
> A remark and a question:
> I would say merge and if not applicable cherry-pick. (to be sure that
> the optimal solution is used)
+1
> Why insist on fast-forward? (In the git-flow document it is emphasised
> that --no-ff should be used at all times)
So, in my proposal I ask developers to merge release (or stable) branches to master (or develop/feature branch) often (say couple of times in the day), using --no-ff will generate a merge commit every time we do that. With fast-forward we’ll get linear history so that’s why I keep insisting on it.
IMO We should only use --no-ff only when we want to have git to track the merge history (i.e. for someone to go and see what feature/branch got merged and what work was done in that merge branch).
Cheers.
>
> thanks, and thanks for seeing the first step to freedom so clearly,
> Daan
>
> On Fri, Aug 8, 2014 at 11:59 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
>> Another note on this blog/workflow/idea:
>>
>> Say I’ve a bug for multiple ACS releases, the way our workflow should be to fix it on the earliest ACS release branch we want to support and then to the next ones, finally on master and then feature/personal branches. Example, you fix on 4.1, then cherry-pick/fix to 4.2, then 4.3, 4.4 and finally master. One can use cherry-picking or merge with fast-forward whatever is applicable.
>>
>> Cheers.
>>
>> On 08-Aug-2014, at 10:25 am, Daan Hoogland <da...@gmail.com> wrote:
>>
>>> And another thank you:
>>>
>>> <quote>
>>> Long-running release branches for long-term support
>>>
>>> What are the main long-running branches in this model?
>>>
>>> We have a master branch – which in Subversion (SVN) terms you would
>>> call trunk – that is stable-ish. It is in a alpha/RC state.
>>> We have stable release branches for each product release we have to
>>> ship updates to.
>>>
>>> Commits always are merged upwards from older to newer branches. If a
>>> fix needs to be applied to stable branch 2.2 for example, a bug fix
>>> branch is created off the stable branch. First it gets merged back to
>>> that branch, and then that branch is merged upwards towards master.
>>> These chains of merges can be several branches long, but this
>>> operation is almost completely automated.
>>> </quote>
>>>
>>> I think this most resembles what we want (source: the link about
>>> atlassian stash from
>>> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/)
>>>
>>> Daan
>>>
>>> On Fri, Aug 8, 2014 at 9:46 AM, Daan Hoogland <da...@gmail.com> wrote:
>>>> thanks Rohit,
>>>>
>>>> I had missed this one. It contains obligatory release management
>>>> knowledge for every keyboard toucher that is allowed to use git:
>>>> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>>>>
>>>> I think if we all read this and then study a bit we don't need to
>>>> discuss or branching model. It will become clear that we are in fact
>>>> doing almost fine and need only small changes.
>>>>
>>>> --
>>>> Daan
>>>
>>>
>>>
>>> --
>>> Daan
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | 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 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.
>
>
>
> --
> Daan
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | 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 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: must read
Posted by Daan Hoogland <da...@gmail.com>.
Rohit,
A remark and a question:
I would say merge and if not applicable cherry-pick. (to be sure that
the optimal solution is used)
Why insist on fast-forward? (In the git-flow document it is emphasised
that --no-ff should be used at all times)
thanks, and thanks for seeing the first step to freedom so clearly,
Daan
On Fri, Aug 8, 2014 at 11:59 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Another note on this blog/workflow/idea:
>
> Say I’ve a bug for multiple ACS releases, the way our workflow should be to fix it on the earliest ACS release branch we want to support and then to the next ones, finally on master and then feature/personal branches. Example, you fix on 4.1, then cherry-pick/fix to 4.2, then 4.3, 4.4 and finally master. One can use cherry-picking or merge with fast-forward whatever is applicable.
>
> Cheers.
>
> On 08-Aug-2014, at 10:25 am, Daan Hoogland <da...@gmail.com> wrote:
>
>> And another thank you:
>>
>> <quote>
>> Long-running release branches for long-term support
>>
>> What are the main long-running branches in this model?
>>
>> We have a master branch – which in Subversion (SVN) terms you would
>> call trunk – that is stable-ish. It is in a alpha/RC state.
>> We have stable release branches for each product release we have to
>> ship updates to.
>>
>> Commits always are merged upwards from older to newer branches. If a
>> fix needs to be applied to stable branch 2.2 for example, a bug fix
>> branch is created off the stable branch. First it gets merged back to
>> that branch, and then that branch is merged upwards towards master.
>> These chains of merges can be several branches long, but this
>> operation is almost completely automated.
>> </quote>
>>
>> I think this most resembles what we want (source: the link about
>> atlassian stash from
>> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/)
>>
>> Daan
>>
>> On Fri, Aug 8, 2014 at 9:46 AM, Daan Hoogland <da...@gmail.com> wrote:
>>> thanks Rohit,
>>>
>>> I had missed this one. It contains obligatory release management
>>> knowledge for every keyboard toucher that is allowed to use git:
>>> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>>>
>>> I think if we all read this and then study a bit we don't need to
>>> discuss or branching model. It will become clear that we are in fact
>>> doing almost fine and need only small changes.
>>>
>>> --
>>> Daan
>>
>>
>>
>> --
>> Daan
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | 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 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.
--
Daan
Re: must read
Posted by Rohit Yadav <ro...@shapeblue.com>.
Another note on this blog/workflow/idea:
Say I’ve a bug for multiple ACS releases, the way our workflow should be to fix it on the earliest ACS release branch we want to support and then to the next ones, finally on master and then feature/personal branches. Example, you fix on 4.1, then cherry-pick/fix to 4.2, then 4.3, 4.4 and finally master. One can use cherry-picking or merge with fast-forward whatever is applicable.
Cheers.
On 08-Aug-2014, at 10:25 am, Daan Hoogland <da...@gmail.com> wrote:
> And another thank you:
>
> <quote>
> Long-running release branches for long-term support
>
> What are the main long-running branches in this model?
>
> We have a master branch – which in Subversion (SVN) terms you would
> call trunk – that is stable-ish. It is in a alpha/RC state.
> We have stable release branches for each product release we have to
> ship updates to.
>
> Commits always are merged upwards from older to newer branches. If a
> fix needs to be applied to stable branch 2.2 for example, a bug fix
> branch is created off the stable branch. First it gets merged back to
> that branch, and then that branch is merged upwards towards master.
> These chains of merges can be several branches long, but this
> operation is almost completely automated.
> </quote>
>
> I think this most resembles what we want (source: the link about
> atlassian stash from
> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/)
>
> Daan
>
> On Fri, Aug 8, 2014 at 9:46 AM, Daan Hoogland <da...@gmail.com> wrote:
>> thanks Rohit,
>>
>> I had missed this one. It contains obligatory release management
>> knowledge for every keyboard toucher that is allowed to use git:
>> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>>
>> I think if we all read this and then study a bit we don't need to
>> discuss or branching model. It will become clear that we are in fact
>> doing almost fine and need only small changes.
>>
>> --
>> Daan
>
>
>
> --
> Daan
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | 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 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: must read
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi Daan,
On 08-Aug-2014, at 10:25 am, Daan Hoogland <da...@gmail.com> wrote:
> And another thank you:
>
> <quote>
> Long-running release branches for long-term support
>
> What are the main long-running branches in this model?
>
> We have a master branch – which in Subversion (SVN) terms you would
> call trunk – that is stable-ish. It is in a alpha/RC state.
> We have stable release branches for each product release we have to
> ship updates to.
>
> Commits always are merged upwards from older to newer branches. If a
> fix needs to be applied to stable branch 2.2 for example, a bug fix
> branch is created off the stable branch. First it gets merged back to
> that branch, and then that branch is merged upwards towards master.
> These chains of merges can be several branches long, but this
> operation is almost completely automated.
> </quote>
>
> I think this most resembles what we want (source: the link about
> atlassian stash from
> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/)
Exactly, thanks for reading it!
This is “what" my proposal thread is about, to bring this in ACS release workflow.
I’ll start a vote on this next week, once we have a healthy discussion around it.
Cheers.
>
> Daan
>
> On Fri, Aug 8, 2014 at 9:46 AM, Daan Hoogland <da...@gmail.com> wrote:
>> thanks Rohit,
>>
>> I had missed this one. It contains obligatory release management
>> knowledge for every keyboard toucher that is allowed to use git:
>> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>>
>> I think if we all read this and then study a bit we don't need to
>> discuss or branching model. It will become clear that we are in fact
>> doing almost fine and need only small changes.
>>
>> --
>> Daan
>
>
>
> --
> Daan
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | 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 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: must read
Posted by Daan Hoogland <da...@gmail.com>.
And another thank you:
<quote>
Long-running release branches for long-term support
What are the main long-running branches in this model?
We have a master branch – which in Subversion (SVN) terms you would
call trunk – that is stable-ish. It is in a alpha/RC state.
We have stable release branches for each product release we have to
ship updates to.
Commits always are merged upwards from older to newer branches. If a
fix needs to be applied to stable branch 2.2 for example, a bug fix
branch is created off the stable branch. First it gets merged back to
that branch, and then that branch is merged upwards towards master.
These chains of merges can be several branches long, but this
operation is almost completely automated.
</quote>
I think this most resembles what we want (source: the link about
atlassian stash from
http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/)
Daan
On Fri, Aug 8, 2014 at 9:46 AM, Daan Hoogland <da...@gmail.com> wrote:
> thanks Rohit,
>
> I had missed this one. It contains obligatory release management
> knowledge for every keyboard toucher that is allowed to use git:
> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>
> I think if we all read this and then study a bit we don't need to
> discuss or branching model. It will become clear that we are in fact
> doing almost fine and need only small changes.
>
> --
> Daan
--
Daan
Re: must read (git.git workflow)
Posted by Leo Simons <LS...@schubergphilis.com>.
git.git workflow is a logical superset of gitflow with shorter branch names. All the basic practices are the same. Unsurprisingly, perhaps :-)
The key difference is the use of long lived stable branches rather than per-release stable branches that wither & die off.
I would guess it’s a little easier to understand coming from current cloudstack practice.
This setup does require a little bit more git-fu to recover from mistakes, and periodic rewind/rebase of integration branches (git has a ‘proposal’ branch if I remember correctly that is `git reset` every now and then). Like most git man-pages it assumes you understand git pretty well :-). Of course only one person needs to do that.
I guess that may also be a good fit for cloudstack which is already used to the release manager announcing these kinds of coordinated shifts and doing branch maintenance.
cheers,
Leo
On Aug 8, 2014, at 9:46 AM, Daan Hoogland <da...@gmail.com> wrote:
> I had missed this one. It contains obligatory release management
> knowledge for every keyboard toucher that is allowed to use git:
> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>
> I think if we all read this and then study a bit we don't need to
> discuss or branching model. It will become clear that we are in fact
> doing almost fine and need only small changes.