[VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

Hello everyone,

With reference to my proposal on changing our release-master commit flow [1], I would like to start a voting thread to decide on the adoption starting 4.5 release. Any opinion, ideas, modifications is welcome to help reach a consensus and improve our present situation.

Today’s Friday so it will be only fair to extend the voting window to more than our usual 72 hours window.
Therefore, we’ll end this voting on Wednesday, 20 August 2014 at 18:00H UTC giving about 5 days of time for people to share what works and what does not. We’ll stop anytime we've three -1s (binding).

Short summary:

- Base line protocol: Continuous changes from release/stable branches to master/unable branches
- Get contributors more engaged with release branches by working (fixing bugs, docs etc.) on release branches first (and not on master)
- Fixes on release branches are recommended (non strict enforcement) go via a hotfix/bugfix branch that get automatically tested by Jenkins, when they are green RMs get the changes to release branch

Long Summary of what we’ll adopt: (I’m skipping writing them on wiki, as this may change/modify in this thread)

- Continuous flow of changes from stable branches to un-stables ones i.e. from release branches to master and from master to features etc. Use of merge —fast-forward is encourages over cherry-picking and —no-ff (no ff will create merge commit). This happens couple of times a day to ensure we get solid/robust changes from release branches (such as bugfixes etc.) on master, any conflicts will be resolved. If we do it continuously we’ll also save ourselves from a big conflict at the end of the release cycle and we’ll also avoid missing/misplacing any commit when cherry-picking.

- After code freeze is declared and release branch is cut out, contributors work on fixing bugs and other changes (such as documentation, build/packaging fixes etc.) first on the release branch (and not master). This is not to restrict anyone working on master, features and other changes can keep landing on master as well. This is to encourage contributors to give more attention to release branches by at least fixing bugs on release branches first and not our current way where we fix it on master and ask RMs to cherry pick it to release branch.

- Changes to release branches can be done by pushing a bugfix/change branch and asking the RM to pick it up if they are tested. Our automated systems can perform checks on such branches too (starting with a suffix that can automatically trigger such builds/tests) and if everything is fine, RMs to land the changes to release branches.

- Nothing is written in stones, this should be change-able. And, this can only work if we all agree to follow this with 4.5

To make the best of this thread, please keep your reply short, constructive and to the point..
Please share your opinion on this proposal with suitable reasons:

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

[1] http://markmail.org/message/ucixhhdbz3ajyv2a

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: [VOTE] Adapting git workflow for release branches

[Daan Hoogland <da...@gmail.com>]

+1


On Fri, Aug 15, 2014 at 1:46 PM, Rohit Yadav <ro...@shapeblue.com>
wrote:

> Thanks Wido!
>
> Let me clarify the baseline protocol or flow of change:
> When fixing a bug, you start with the oldest ACS release you want to fix
> it for say 4.2 and go on with 4.3, then 4.4 etc. until you land master,
> followed by feature/personal branches. When in doubt, use the flow which is
> from stable/firm branches to less firm branches.
>
> In the above example, after you fix it on 4.2 you should use merge
> -ff-only (-ff is recommended but you may also you cherry-picking or fix it
> manually in case of major conflicts due to code divergence) to 4.3, 4.4,
> master and so on. If you merge -ff a released branch say 4.2 to 4.3, it
> should *not* cause any conflict as 4.2’s history is already with 4.3 (think
> them as link lists) so it should result in one commit only (that’s the
> bugfix and ideally no conflicts).
>
> Cheers.
>
> On 15-Aug-2014, at 1:30 pm, Wido den Hollander <wi...@widodh.nl> wrote:
>
> >
> >
> > On 08/15/2014 12:25 PM, Rohit Yadav wrote:
> >> Hello everyone,
> >>
> >> With reference to my proposal on changing our release-master commit
> flow [1], I would like to start a voting thread to decide on the adoption
> starting 4.5 release. Any opinion, ideas, modifications is welcome to help
> reach a consensus and improve our present situation.
> >>
> >> Today’s Friday so it will be only fair to extend the voting window to
> more than our usual 72 hours window.
> >> Therefore, we’ll end this voting on Wednesday, 20 August 2014 at 18:00H
> UTC giving about 5 days of time for people to share what works and what
> does not. We’ll stop anytime we've three -1s (binding).
> >>
> >> Short summary:
> >>
> >> - Base line protocol: Continuous changes from release/stable branches
> to master/unable branches
> >> - Get contributors more engaged with release branches by working
> (fixing bugs, docs etc.) on release branches first (and not on master)
> >> - Fixes on release branches are recommended (non strict enforcement) go
> via a hotfix/bugfix branch that get automatically tested by Jenkins, when
> they are green RMs get the changes to release branch
> >>
> >> Long Summary of what we’ll adopt: (I’m skipping writing them on wiki,
> as this may change/modify in this thread)
> >>
> >> - Continuous flow of changes from stable branches to un-stables ones
> i.e. from release branches to master and from master to features etc. Use
> of merge —fast-forward is encourages over cherry-picking and —no-ff (no ff
> will create merge commit). This happens couple of times a day to ensure we
> get solid/robust changes from release branches (such as bugfixes etc.) on
> master, any conflicts will be resolved. If we do it continuously we’ll also
> save ourselves from a big conflict at the end of the release cycle and
> we’ll also avoid missing/misplacing any commit when cherry-picking.
> >>
> >> - After code freeze is declared and release branch is cut out,
> contributors work on fixing bugs and other changes (such as documentation,
> build/packaging fixes etc.) first on the release branch (and not master).
> This is not to restrict anyone working on master, features and other
> changes can keep landing on master as well. This is to encourage
> contributors to give more attention to release branches by at least fixing
> bugs on release branches first and not our current way where we fix it on
> master and ask RMs to cherry pick it to release branch.
> >>
> >> - Changes to release branches can be done by pushing a bugfix/change
> branch and asking the RM to pick it up if they are tested. Our automated
> systems can perform checks on such branches too (starting with a suffix
> that can automatically trigger such builds/tests) and if everything is
> fine, RMs to land the changes to release branches.
> >>
> >> - Nothing is written in stones, this should be change-able. And, this
> can only work if we all agree to follow this with 4.5
> >>
> >> To make the best of this thread, please keep your reply short,
> constructive and to the point..
> >> Please share your opinion on this proposal with suitable reasons:
> >>
> >> [ ] +1  approve
> >
> > +1 for me.
> >
> > The current system with the branches has frustrated me a couple of
> times. This way of branching can be seen with multiple projects and seems
> to be working there just fine.
> >
> >> [ ] +0  no opinion
> >> [ ] -1  disapprove (and reason why)
> >>
> >> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
> >>
> >> 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.
>
> 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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

Thanks Wido!

Let me clarify the baseline protocol or flow of change:
When fixing a bug, you start with the oldest ACS release you want to fix it for say 4.2 and go on with 4.3, then 4.4 etc. until you land master, followed by feature/personal branches. When in doubt, use the flow which is from stable/firm branches to less firm branches.

In the above example, after you fix it on 4.2 you should use merge -ff-only (-ff is recommended but you may also you cherry-picking or fix it manually in case of major conflicts due to code divergence) to 4.3, 4.4, master and so on. If you merge -ff a released branch say 4.2 to 4.3, it should *not* cause any conflict as 4.2’s history is already with 4.3 (think them as link lists) so it should result in one commit only (that’s the bugfix and ideally no conflicts).

Cheers.

On 15-Aug-2014, at 1:30 pm, Wido den Hollander <wi...@widodh.nl> wrote:

>
>
> On 08/15/2014 12:25 PM, Rohit Yadav wrote:
>> Hello everyone,
>>
>> With reference to my proposal on changing our release-master commit flow [1], I would like to start a voting thread to decide on the adoption starting 4.5 release. Any opinion, ideas, modifications is welcome to help reach a consensus and improve our present situation.
>>
>> Today’s Friday so it will be only fair to extend the voting window to more than our usual 72 hours window.
>> Therefore, we’ll end this voting on Wednesday, 20 August 2014 at 18:00H UTC giving about 5 days of time for people to share what works and what does not. We’ll stop anytime we've three -1s (binding).
>>
>> Short summary:
>>
>> - Base line protocol: Continuous changes from release/stable branches to master/unable branches
>> - Get contributors more engaged with release branches by working (fixing bugs, docs etc.) on release branches first (and not on master)
>> - Fixes on release branches are recommended (non strict enforcement) go via a hotfix/bugfix branch that get automatically tested by Jenkins, when they are green RMs get the changes to release branch
>>
>> Long Summary of what we’ll adopt: (I’m skipping writing them on wiki, as this may change/modify in this thread)
>>
>> - Continuous flow of changes from stable branches to un-stables ones i.e. from release branches to master and from master to features etc. Use of merge —fast-forward is encourages over cherry-picking and —no-ff (no ff will create merge commit). This happens couple of times a day to ensure we get solid/robust changes from release branches (such as bugfixes etc.) on master, any conflicts will be resolved. If we do it continuously we’ll also save ourselves from a big conflict at the end of the release cycle and we’ll also avoid missing/misplacing any commit when cherry-picking.
>>
>> - After code freeze is declared and release branch is cut out, contributors work on fixing bugs and other changes (such as documentation, build/packaging fixes etc.) first on the release branch (and not master). This is not to restrict anyone working on master, features and other changes can keep landing on master as well. This is to encourage contributors to give more attention to release branches by at least fixing bugs on release branches first and not our current way where we fix it on master and ask RMs to cherry pick it to release branch.
>>
>> - Changes to release branches can be done by pushing a bugfix/change branch and asking the RM to pick it up if they are tested. Our automated systems can perform checks on such branches too (starting with a suffix that can automatically trigger such builds/tests) and if everything is fine, RMs to land the changes to release branches.
>>
>> - Nothing is written in stones, this should be change-able. And, this can only work if we all agree to follow this with 4.5
>>
>> To make the best of this thread, please keep your reply short, constructive and to the point..
>> Please share your opinion on this proposal with suitable reasons:
>>
>> [ ] +1  approve
>
> +1 for me.
>
> The current system with the branches has frustrated me a couple of times. This way of branching can be seen with multiple projects and seems to be working there just fine.
>
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
>>
>> 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.

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: [VOTE] Adapting git workflow for release branches

[Wido den Hollander <wi...@widodh.nl>]

On 08/15/2014 12:25 PM, Rohit Yadav wrote:
> Hello everyone,
>
> With reference to my proposal on changing our release-master commit flow [1], I would like to start a voting thread to decide on the adoption starting 4.5 release. Any opinion, ideas, modifications is welcome to help reach a consensus and improve our present situation.
>
> Today’s Friday so it will be only fair to extend the voting window to more than our usual 72 hours window.
> Therefore, we’ll end this voting on Wednesday, 20 August 2014 at 18:00H UTC giving about 5 days of time for people to share what works and what does not. We’ll stop anytime we've three -1s (binding).
>
> Short summary:
>
> - Base line protocol: Continuous changes from release/stable branches to master/unable branches
> - Get contributors more engaged with release branches by working (fixing bugs, docs etc.) on release branches first (and not on master)
> - Fixes on release branches are recommended (non strict enforcement) go via a hotfix/bugfix branch that get automatically tested by Jenkins, when they are green RMs get the changes to release branch
>
> Long Summary of what we’ll adopt: (I’m skipping writing them on wiki, as this may change/modify in this thread)
>
> - Continuous flow of changes from stable branches to un-stables ones i.e. from release branches to master and from master to features etc. Use of merge —fast-forward is encourages over cherry-picking and —no-ff (no ff will create merge commit). This happens couple of times a day to ensure we get solid/robust changes from release branches (such as bugfixes etc.) on master, any conflicts will be resolved. If we do it continuously we’ll also save ourselves from a big conflict at the end of the release cycle and we’ll also avoid missing/misplacing any commit when cherry-picking.
>
> - After code freeze is declared and release branch is cut out, contributors work on fixing bugs and other changes (such as documentation, build/packaging fixes etc.) first on the release branch (and not master). This is not to restrict anyone working on master, features and other changes can keep landing on master as well. This is to encourage contributors to give more attention to release branches by at least fixing bugs on release branches first and not our current way where we fix it on master and ask RMs to cherry pick it to release branch.
>
> - Changes to release branches can be done by pushing a bugfix/change branch and asking the RM to pick it up if they are tested. Our automated systems can perform checks on such branches too (starting with a suffix that can automatically trigger such builds/tests) and if everything is fine, RMs to land the changes to release branches.
>
> - Nothing is written in stones, this should be change-able. And, this can only work if we all agree to follow this with 4.5
>
> To make the best of this thread, please keep your reply short, constructive and to the point..
> Please share your opinion on this proposal with suitable reasons:
>
> [ ] +1  approve

+1 for me.

The current system with the branches has frustrated me a couple of 
times. This way of branching can be seen with multiple projects and 
seems to be working there just fine.

> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
>
> 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: [VOTE] Adapting git workflow for release branches

[Edison Su <Ed...@citrix.com>]

> -----Original Message-----
> From: Nate Gordon [mailto:nate.gordon@appcore.com]
> Sent: Monday, August 18, 2014 7:36 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Adapting git workflow for release branches
> 
> +1 This is at least is a step in the right direction. I don't think this
> goes far enough, but I'm not going to stand in the way of making forward
> progress and nothing in this proposal seems to be a bad idea.
> 
> I would also encourage those who are against this to think about if this
> proposal at least moves us towards your ideal solution. If you look at most
I am not sure it's towards the "ideal" solution or not. 
I think all we agree that current code quality control has issues(no CI, no code review). If the assumption is true,
then how we gonna solve the issues?
There is proposal to add gerrit as code review, but rejected by community due to issues related to Apache policy.
Another Apache project is following github pull request model: http://wiki.apache.org/cordova/GitWorkflow, we could adopt this model as well, if gerrit is impossible.
So you see, above two proposals have different git work flow, but they both lead to the same goal(more control on the code quality).
Without thinking about the big picture, it's really not that useful to change our current work flow.
If the community can agree on the basic issue(no CI, no code review) we have today, then we can move on the fix it.


> modern software development life cycles, the trend is for smaller more
> frequent changes. I would rather see us make continuous small
> improvements than debating forever on the ideal solution that changes
> everything.
> 
> Thanks,
> 
> -Nate
> 
> 
> On Mon, Aug 18, 2014 at 12:45 AM, Rajani Karuturi <ra...@apache.org>
> wrote:
> 
> > +1 for merges(no-ff) from stable to unstable.
> > There are pros and cons of ff and no-ff. I prefer no-ff.
> >
> > -1 on frequent merges in RC stage.
> > IMO, we shouldn't cut a release a branch until we are reasonably sure
> > that we have a stable branch. Which would mean everyone working on the
> release.
> > once we cut the branch, we start working towards the next release and
> > the release focus is lost.
> > I also prefer a single merge after the release is voted. (The changes
> > should be minimal)
> >
> > ~Rajani
> >
> >
> > On Fri, Aug 15, 2014 at 3:55 PM, Rohit Yadav
> > <ro...@shapeblue.com>
> > wrote:
> >
> > > Hello everyone,
> > >
> > > With reference to my proposal on changing our release-master commit
> > > flow [1], I would like to start a voting thread to decide on the
> > > adoption starting 4.5 release. Any opinion, ideas, modifications is
> > > welcome to
> > help
> > > reach a consensus and improve our present situation.
> > >
> > > Today’s Friday so it will be only fair to extend the voting window
> > > to
> > more
> > > than our usual 72 hours window.
> > > Therefore, we’ll end this voting on Wednesday, 20 August 2014 at
> > > 18:00H UTC giving about 5 days of time for people to share what
> > > works and what does not. We’ll stop anytime we've three -1s (binding).
> > >
> > > Short summary:
> > >
> > > - Base line protocol: Continuous changes from release/stable
> > > branches to master/unable branches
> > > - Get contributors more engaged with release branches by working
> > > (fixing bugs, docs etc.) on release branches first (and not on
> > > master)
> > > - Fixes on release branches are recommended (non strict enforcement)
> > > go via a hotfix/bugfix branch that get automatically tested by
> > > Jenkins, when they are green RMs get the changes to release branch
> > >
> > > Long Summary of what we’ll adopt: (I’m skipping writing them on
> > > wiki, as this may change/modify in this thread)
> > >
> > > - Continuous flow of changes from stable branches to un-stables ones i.e.
> > > from release branches to master and from master to features etc. Use
> > > of merge —fast-forward is encourages over cherry-picking and —no-ff
> > > (no ff will create merge commit). This happens couple of times a day
> > > to ensure
> > we
> > > get solid/robust changes from release branches (such as bugfixes
> > > etc.) on master, any conflicts will be resolved. If we do it
> > > continuously we’ll
> > also
> > > save ourselves from a big conflict at the end of the release cycle
> > > and we’ll also avoid missing/misplacing any commit when cherry-picking.
> > >
> > > - After code freeze is declared and release branch is cut out,
> > > contributors work on fixing bugs and other changes (such as
> > documentation,
> > > build/packaging fixes etc.) first on the release branch (and not master).
> > > This is not to restrict anyone working on master, features and other
> > > changes can keep landing on master as well. This is to encourage
> > > contributors to give more attention to release branches by at least
> > fixing
> > > bugs on release branches first and not our current way where we fix
> > > it on master and ask RMs to cherry pick it to release branch.
> > >
> > > - Changes to release branches can be done by pushing a bugfix/change
> > > branch and asking the RM to pick it up if they are tested. Our
> > > automated systems can perform checks on such branches too (starting
> > > with a suffix that can automatically trigger such builds/tests) and
> > > if everything is fine, RMs to land the changes to release branches.
> > >
> > > - Nothing is written in stones, this should be change-able. And,
> > > this can only work if we all agree to follow this with 4.5
> > >
> > > To make the best of this thread, please keep your reply short,
> > > constructive and to the point..
> > > Please share your opinion on this proposal with suitable reasons:
> > >
> > > [ ] +1  approve
> > > [ ] +0  no opinion
> > > [ ] -1  disapprove (and reason why)
> > >
> > > [1] http://markmail.org/message/ucixhhdbz3ajyv2a
> > >
> > > 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.
> > >
> >
> 
> 
> 
> --
> 
> 
> *Nate Gordon*Director of Technology | Appcore - the business of cloud
> computing®
> 
> Office +1.800.735.7104  |  Direct +1.515.612.7787 nate.gordon@appcore.com
> |  www.appcore.com
> 
> ----------------------------------------------------------------------
> 
> The information in this message is intended for the named recipients only.
> It may contain information that is privileged, confidential or otherwise
> protected from disclosure. If you are not the intended recipient, you are
> hereby notified that any disclosure, copying, distribution, or the taking of any
> action in reliance on the contents of this message is strictly prohibited. If you
> have received this e-mail in error, do not print it or disseminate it or its
> contents. In such event, please notify the sender by return e-mail and delete
> the e-mail file immediately thereafter. Thank you.

Re: [VOTE] Adapting git workflow for release branches

[Nate Gordon <na...@appcore.com>]

+1 This is at least is a step in the right direction. I don't think this
goes far enough, but I'm not going to stand in the way of making forward
progress and nothing in this proposal seems to be a bad idea.

I would also encourage those who are against this to think about if this
proposal at least moves us towards your ideal solution. If you look at most
modern software development life cycles, the trend is for smaller more
frequent changes. I would rather see us make continuous small improvements
than debating forever on the ideal solution that changes everything.

Thanks,

-Nate


On Mon, Aug 18, 2014 at 12:45 AM, Rajani Karuturi <ra...@apache.org> wrote:

> +1 for merges(no-ff) from stable to unstable.
> There are pros and cons of ff and no-ff. I prefer no-ff.
>
> -1 on frequent merges in RC stage.
> IMO, we shouldn't cut a release a branch until we are reasonably sure that
> we have a stable branch. Which would mean everyone working on the release.
> once we cut the branch, we start working towards the next release and the
> release focus is lost.
> I also prefer a single merge after the release is voted. (The changes
> should be minimal)
>
> ~Rajani
>
>
> On Fri, Aug 15, 2014 at 3:55 PM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
>
> > Hello everyone,
> >
> > With reference to my proposal on changing our release-master commit flow
> > [1], I would like to start a voting thread to decide on the adoption
> > starting 4.5 release. Any opinion, ideas, modifications is welcome to
> help
> > reach a consensus and improve our present situation.
> >
> > Today’s Friday so it will be only fair to extend the voting window to
> more
> > than our usual 72 hours window.
> > Therefore, we’ll end this voting on Wednesday, 20 August 2014 at 18:00H
> > UTC giving about 5 days of time for people to share what works and what
> > does not. We’ll stop anytime we've three -1s (binding).
> >
> > Short summary:
> >
> > - Base line protocol: Continuous changes from release/stable branches to
> > master/unable branches
> > - Get contributors more engaged with release branches by working (fixing
> > bugs, docs etc.) on release branches first (and not on master)
> > - Fixes on release branches are recommended (non strict enforcement) go
> > via a hotfix/bugfix branch that get automatically tested by Jenkins, when
> > they are green RMs get the changes to release branch
> >
> > Long Summary of what we’ll adopt: (I’m skipping writing them on wiki, as
> > this may change/modify in this thread)
> >
> > - Continuous flow of changes from stable branches to un-stables ones i.e.
> > from release branches to master and from master to features etc. Use of
> > merge —fast-forward is encourages over cherry-picking and —no-ff (no ff
> > will create merge commit). This happens couple of times a day to ensure
> we
> > get solid/robust changes from release branches (such as bugfixes etc.) on
> > master, any conflicts will be resolved. If we do it continuously we’ll
> also
> > save ourselves from a big conflict at the end of the release cycle and
> > we’ll also avoid missing/misplacing any commit when cherry-picking.
> >
> > - After code freeze is declared and release branch is cut out,
> > contributors work on fixing bugs and other changes (such as
> documentation,
> > build/packaging fixes etc.) first on the release branch (and not master).
> > This is not to restrict anyone working on master, features and other
> > changes can keep landing on master as well. This is to encourage
> > contributors to give more attention to release branches by at least
> fixing
> > bugs on release branches first and not our current way where we fix it on
> > master and ask RMs to cherry pick it to release branch.
> >
> > - Changes to release branches can be done by pushing a bugfix/change
> > branch and asking the RM to pick it up if they are tested. Our automated
> > systems can perform checks on such branches too (starting with a suffix
> > that can automatically trigger such builds/tests) and if everything is
> > fine, RMs to land the changes to release branches.
> >
> > - Nothing is written in stones, this should be change-able. And, this can
> > only work if we all agree to follow this with 4.5
> >
> > To make the best of this thread, please keep your reply short,
> > constructive and to the point..
> > Please share your opinion on this proposal with suitable reasons:
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > [1] http://markmail.org/message/ucixhhdbz3ajyv2a
> >
> > 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.
> >
>



-- 


*Nate Gordon*Director of Technology | Appcore - the business of cloud
computing®

Office +1.800.735.7104  |  Direct +1.515.612.7787
nate.gordon@appcore.com  |  www.appcore.com

----------------------------------------------------------------------

The information in this message is intended for the named recipients only.
It may contain information that is privileged, confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution, or the taking
of any action in reliance on the contents of this message is strictly
prohibited. If you have received this e-mail in error, do not print it or
disseminate it or its contents. In such event, please notify the sender by
return e-mail and delete the e-mail file immediately thereafter. Thank you.

Re: [VOTE] Adapting git workflow for release branches

[Rajani Karuturi <ra...@apache.org>]

+1 for merges(no-ff) from stable to unstable.
There are pros and cons of ff and no-ff. I prefer no-ff.

-1 on frequent merges in RC stage.
IMO, we shouldn't cut a release a branch until we are reasonably sure that
we have a stable branch. Which would mean everyone working on the release.
once we cut the branch, we start working towards the next release and the
release focus is lost.
I also prefer a single merge after the release is voted. (The changes
should be minimal)

~Rajani


On Fri, Aug 15, 2014 at 3:55 PM, Rohit Yadav <ro...@shapeblue.com>
wrote:

> Hello everyone,
>
> With reference to my proposal on changing our release-master commit flow
> [1], I would like to start a voting thread to decide on the adoption
> starting 4.5 release. Any opinion, ideas, modifications is welcome to help
> reach a consensus and improve our present situation.
>
> Today’s Friday so it will be only fair to extend the voting window to more
> than our usual 72 hours window.
> Therefore, we’ll end this voting on Wednesday, 20 August 2014 at 18:00H
> UTC giving about 5 days of time for people to share what works and what
> does not. We’ll stop anytime we've three -1s (binding).
>
> Short summary:
>
> - Base line protocol: Continuous changes from release/stable branches to
> master/unable branches
> - Get contributors more engaged with release branches by working (fixing
> bugs, docs etc.) on release branches first (and not on master)
> - Fixes on release branches are recommended (non strict enforcement) go
> via a hotfix/bugfix branch that get automatically tested by Jenkins, when
> they are green RMs get the changes to release branch
>
> Long Summary of what we’ll adopt: (I’m skipping writing them on wiki, as
> this may change/modify in this thread)
>
> - Continuous flow of changes from stable branches to un-stables ones i.e.
> from release branches to master and from master to features etc. Use of
> merge —fast-forward is encourages over cherry-picking and —no-ff (no ff
> will create merge commit). This happens couple of times a day to ensure we
> get solid/robust changes from release branches (such as bugfixes etc.) on
> master, any conflicts will be resolved. If we do it continuously we’ll also
> save ourselves from a big conflict at the end of the release cycle and
> we’ll also avoid missing/misplacing any commit when cherry-picking.
>
> - After code freeze is declared and release branch is cut out,
> contributors work on fixing bugs and other changes (such as documentation,
> build/packaging fixes etc.) first on the release branch (and not master).
> This is not to restrict anyone working on master, features and other
> changes can keep landing on master as well. This is to encourage
> contributors to give more attention to release branches by at least fixing
> bugs on release branches first and not our current way where we fix it on
> master and ask RMs to cherry pick it to release branch.
>
> - Changes to release branches can be done by pushing a bugfix/change
> branch and asking the RM to pick it up if they are tested. Our automated
> systems can perform checks on such branches too (starting with a suffix
> that can automatically trigger such builds/tests) and if everything is
> fine, RMs to land the changes to release branches.
>
> - Nothing is written in stones, this should be change-able. And, this can
> only work if we all agree to follow this with 4.5
>
> To make the best of this thread, please keep your reply short,
> constructive and to the point..
> Please share your opinion on this proposal with suitable reasons:
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
>
> 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: [VOTE] Adapting git workflow for release branches

[Brian Federle <Br...@citrix.com>]

Also a -1 on this, from all points made in previous replies.

Thank you,
Brian

-----Original Message-----
From: Jessica Wang [mailto:Jessica.Wang@citrix.com] 
Sent: Monday, August 18, 2014 9:52 AM
To: dev@cloudstack.apache.org
Cc: Edison Su; Min Chen; Sheng Yang; rohit.yadav@shapeblue.com
Subject: RE: [VOTE] Adapting git workflow for release branches

I agree with Edison.
I am -1 on this as well.


-----Original Message-----
From: Edison Su [mailto:Edison.su@citrix.com]
Sent: Saturday, August 16, 2014 12:11 PM
To: dev
Subject: RE: [VOTE] Adapting git workflow for release branches

I agree with what Min said on thread: http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with your answer:
Currently we don't have a CI running continuously, no code review, it's too risky to let developer check in whatever commit they want into release branch. RM needs to have to control over what commit should be put into release branch and what should not, otherwise, we could get into a stage where no control on the quality.
How RM will do the control, that's something we could discuss. I know, current model is not scale, as RM needs to manually cherry pick commits into release branch. The way I thinking about, is all the commits put into release branch, must be put into review board, or gerrit, must be passed by CI and reviewers, then the commits can be put into release branch. 
For above reason, I am -1(binding) on your proposal for now until we solve the quality control problem. 

> -----Original Message-----
> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> Sent: Friday, August 15, 2014 3:25 AM
> To: dev
> Subject: [VOTE] Adapting git workflow for release branches
> 
> Hello everyone,
> 
> With reference to my proposal on changing our release-master commit 
> flow [1], I would like to start a voting thread to decide on the 
> adoption starting 4.5 release. Any opinion, ideas, modifications is 
> welcome to help reach a consensus and improve our present situation.
> 
> Today's Friday so it will be only fair to extend the voting window to 
> more than our usual 72 hours window.
> Therefore, we'll end this voting on Wednesday, 20 August 2014 at 
> 18:00H UTC giving about 5 days of time for people to share what works 
> and what does not. We'll stop anytime we've three -1s (binding).
> 
> Short summary:
> 
> - Base line protocol: Continuous changes from release/stable branches 
> to master/unable branches
> - Get contributors more engaged with release branches by working 
> (fixing bugs, docs etc.) on release branches first (and not on master)
> - Fixes on release branches are recommended (non strict enforcement) 
> go via a hotfix/bugfix branch that get automatically tested by 
> Jenkins, when they are green RMs get the changes to release branch
> 
> Long Summary of what we'll adopt: (I'm skipping writing them on wiki, 
> as this may change/modify in this thread)
> 
> - Continuous flow of changes from stable branches to un-stables ones i.e.
> from release branches to master and from master to features etc. Use 
> of merge -fast-forward is encourages over cherry-picking and -no-ff 
> (no ff will create merge commit). This happens couple of times a day 
> to ensure we get solid/robust changes from release branches (such as 
> bugfixes etc.) on master, any conflicts will be resolved. If we do it 
> continuously we'll also save ourselves from a big conflict at the end 
> of the release cycle and we'll also avoid missing/misplacing any commit when cherry-picking.
> 
> - After code freeze is declared and release branch is cut out, 
> contributors work on fixing bugs and other changes (such as 
> documentation, build/packaging fixes etc.) first on the release branch 
> (and not master). This is not to restrict anyone working on master, 
> features and other changes can keep landing on master as well. This is 
> to encourage contributors to give more attention to release branches 
> by at least fixing bugs on release branches first and not our current 
> way where we fix it on master and ask RMs to cherry pick it to release branch.
> 
> - Changes to release branches can be done by pushing a bugfix/change 
> branch and asking the RM to pick it up if they are tested. Our 
> automated systems can perform checks on such branches too (starting 
> with a suffix that can automatically trigger such builds/tests) and if 
> everything is fine, RMs to land the changes to release branches.
> 
> - Nothing is written in stones, this should be change-able. And, this 
> can only work if we all agree to follow this with 4.5
> 
> To make the best of this thread, please keep your reply short, 
> constructive and to the point..
> Please share your opinion on this proposal with suitable reasons:
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
> 
> 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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

On 19-Aug-2014, at 5:08 pm, Pierre-Luc Dion <pd...@cloudops.com> wrote:
> +1 ,  CI shouldn't be another topic?
>
> What is required or missing to have CI in place?

We need more servers for running Jenkins slaves on them and automation around kicking builds for hotfixes that have a for release branches.
We can work on them gradually.

About how to do it -- if you’re a committer you create a branch and if you’re not you submit your patch via reviewboard and explicitly email the RM. And, finally it will be at RM’s discretion and responsibility to check the CI build status (if available that is) and decide what goes in and what not.

As for documentation fixes and build fixes, if RM allows you may commit them directly to the release branch or follow the above procedure.

There is a good recommendation to have co-pilots available to the RMs to speed the above process and help out when the RM is not available, but to introduce that we’ll need another proposal thread and another voting thread.

IMHO just like how we should ideally commit, I don’t aim to solve several issues with this voting thread. If you’ve good idea please start a proposal/voting thread of its own. This is why I don’t want to dilute the 2 main things I want to introduce with this thread:

- Get more community participation and attention on release branches
- A guidelines for flow of changes across release/maintenance branches and from release branch(es) to master branch (viz. the baseline protocol)

Kindly stick your views to the above only and I request not to encourage dilution of the voting agendas.

Cheers.

>
>
> *Pierre-Luc DION*
> Architecte de Solution Cloud | Cloud Solutions Architect
> t 855.652.5683
>
> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
>
>
> On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
>
>>
>> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen <ru...@gmail.com> wrote:
>>> Say you grab a patch from review board and stick it in a hotfix branch,
>> test that …call for merge on release branch.
>>> Do we *merge* to master or can we apply the patch directly to master
>> (git am -s…) ?
>>
>> Once the hotfix branch is merged on release branch, we would merge the
>> release branch to master, that will bring the hotfix on master as well.
>>
>> We don’t want to encourage working on master for fixes that qualify for
>> release branches directly so ideally we should not git am -s the patch on
>> master. But there is scope for non-strictness for a situation needing git
>> am -s <patch> on master directly, it would be at the discretion of the RM
>> and committers.
>>
>> 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.
>>

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: [VOTE] Adapting git workflow for release branches

[Jessica Wang <Je...@citrix.com>]

My opinion is totally the same as Min's.


-----Original Message-----
From: Min Chen [mailto:min.chen@citrix.com] 
Sent: Tuesday, August 19, 2014 11:12 AM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Adapting git workflow for release branches

I personally don't think introducing CI or gerrit or github pull request
will take away a committer's privilege to commit. If you are a stakeholder
who really care about your product, you will not be scared away by this
extra enforcement, this will actually make our cloudstack ecosystem better
and healthier, and will also benefit other contributors in the same
community. To me, this is not a punishment per se, your code is just not
directly committed in, and you can enhance it and commit later. We are not
even requesting for bug-free code, I know, that is not possible in
software world, but at least we should have some stableness in our code to
not block other peers. As far as I know, Linux has much better control
about what patch to be pulled in, which makes it much more stabler than
us. As for your traffic example, at least there we have DMV road test,
traffic light, traffic patrol infrastructure to have basic guard.
CI/gerrit are just like those basic enforcement infrastructure for
CloudStack development process.

I don't want this to become a two-person argument forever. I already
clearly explained my ideas and takes on this. Let's hear others.

Thanks
-min

On 8/19/14 10:55 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:

>tl;dr? hope you read it;
>
>On 19-Aug-2014, at 7:10 pm, Min Chen <mi...@citrix.com> wrote:
>
>> I will hesitate on this "No enforcement" approach in the flow. I bet
>>that
>> without some kind of enforcement, based on past experience, after one
>
>Stakeholder will always care. The system should be optimistic to allow
>things in and not to punish in advance.
>That’s how many scalable opensource project such as Linux, Firefox and
>our own Apache works (people over code that is).
>
>If you’ve any ideas please share. We’ve to find a “non-strict”
>enforcement to get best of all things and I don’t have a solution right
>now to suggest.
>
>“Strict enforcement” won’t be scalable anyway, hackers always find way
>around gaming the system.
>
>Unicorns, Santas and bug-less code perhaps don’t exist IMHO so may never
>guarantee code quality but only improve over time. Even things like
>pacemakers, realtime systems used in mining, surgery, aerospace, mars
>rover etc; openssl (heartbleed) have bugs and issues. This is not to say
>that we should not have code reviews, other processes and automated
>build/CI/smoke-tests are “not” needed, they are needed but they “should"
>come only gradually. I also think improvements are better severed in
>small nibbles than a one big main course.
>
>In my past startup, last year, I helped them introduce a non-strict code
>reviewing process and what it did was not to scare anyone but slowly and
>gradually everyone started using code reviews and that became a process
>now. What I learnt was that people like slow changes (don’t put the frog
>in hot water), processes should be effortless and invisible (you don’t
>have to think much on how to do it, like say driving a car or touch
>typing on keyboard), and a cultural change is best implemented without
>enforcement. For example, in a many countries people don’t honk i.e. the
>culture even if no one gets a ticket for honking which is my point we
>need an understanding, a guideline, a protocol to implement a culture not
>an “enforcement” or team of police.
>
>> release, we will come together to discuss flaw in our flow again:) Sorry
>> if I am too pessimistic on this.
>
>To introduce an enforcement would mean take away a committer’s privilege
>to commit. If you have some ideas start a thread.
>
>IMO “pessimistic approach" is not a good approach — you don't ban or
>restrict people driving cars just because of accidents or ban the
>Internet just because there are things you don’t like on it, or put
>people in jail just because they can commit a crime in future. I would
>want an open and transparent workflow/protocol/guideline that is
>agreeable to all/most of us and that does not impose any restrictions.
>
>Cheers.
>
>>
>> Thanks
>> -min
>>
>> On 8/19/14 10:00 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>
>>> Hi,
>>>
>>> On 19-Aug-2014, at 6:48 pm, Min Chen <mi...@citrix.com> wrote:
>>>
>>>> In that case, we should call out this procedure
>>>>
>>>> If (you¹re a committer) {
>>>> Go create a hotfix branch and ask RM to pick it up
>>>> } else {
>>>> Go upload your patch and get RM to review your request from
>>>>reviewboard
>>>> }
>>>>
>>>>
>>>> in your proposal. I don't want people to have a misunderstanding that
>>>> with
>>>> this proposal, RM is not needed anymore. Actually, RM is MORE
>>>>IMPORTANT
>>>> with this proposal.
>>>
>>> Yes.
>>>
>>>> Also, we should also call out the enforcement plan for this procedure.
>>>
>>> Subjective. All committers have privilege to commit so enforcement will
>>> be unnecessary, instead if you find an issue with anyone/anything you
>>> raise it privately or on public dev ML just like we do it now.
>>>
>>>> What happens if somebody still directly commits to release branch
>>>>after
>>>> it
>>>> is cut? Ideally, based on this proposal, after RC is cut, we should
>>>>only
>>>> see branch merge/cherry-pick done by RM. If not, RM should revert it
>>>>to
>>>> enforce the flow.
>>>
>>> At RM’s discretion.
>>>
>>> Cheers.
>>>
>>>>
>>>> Thanks
>>>> -min
>>>>
>>>>
>>>>
>>>>
>>>> On 8/19/14 9:19 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> On 19-Aug-2014, at 5:34 pm, Pierre-Luc Dion <pd...@cloudops.com>
>>>>>wrote:
>>>>>
>>>>>> Thanks Min for the comment, make sense.
>>>>>>
>>>>>> Rohit,  how do we plan to managed merge request or submit one?  I
>>>>>> don't
>>>>>> think using the mailing list to keep track of merge request is good,
>>>>>> does
>>>>>> https://reviews.apache.org/account/login/ is keep up to date and all
>>>>>> merge
>>>>>> request should go there ?
>>>>>
>>>>> If (you¹re a committer) {
>>>>> Go create a hotfix branch and ask RM to pick it up
>>>>> } else {
>>>>> Go upload your patch and get RM to review your request from
>>>>>reviewboard
>>>>> }
>>>>>
>>>>>> What about using Jira to follow merge request ? maybe by having a
>>>>>> 'merge-request' issue type as sub-task?
>>>>>
>>>>> You may do that as long as RMs are okay with that. We don¹t want
>>>>>people
>>>>> to attack RMs from too many of channels such as reviewboard, jira,
>>>>> twitter, fb, linkedin and whatnot; sticking to just using email is
>>>>> recommended.
>>>>>
>>>>>> Also I'm a bit confuse for some commit cases:
>>>>>>
>>>>>> Let say that I want to fix the release version display in the API
>>>>>>doc,
>>>>>> it
>>>>>> is not code related right not it show as 4.2.0, it's not a bugfix
>>>>>>or a
>>>>>> new
>>>>>> feature, so should I create branch + merge request  or this type of
>>>>>> commit
>>>>>> could be push directly in the release branch (ie: 4.4) ?
>>>>>
>>>>> Such cases will ³depend" on your chemistry with the RM, if they¹re
>>>>>cool
>>>>> you go ahead alongwith them and fix doc/build fixes directly on
>>>>>release
>>>>> (4.4 in the example) branch.
>>>>>
>>>>> This is a reason as to why this proposal is flexible, and it does not
>>>>> introduce any policing but gives a guideline for people to follow.
>>>>>
>>>>> Lastly, checking out branches and working on them using git is not
>>>>> expensive at all, just few keyboard strokes maybe so just don¹t be
>>>>> afraid.
>>>>>
>>>>> Also, for multiple fixes feel free to do several bugfixes and ask the
>>>>> RM
>>>>> to pick the fixes from that (hot/bug) fix branch.
>>>>>
>>>>> HTH, cheers.
>>>>>
>>>>>> Sorry if I add confusion...
>>>>>>
>>>>>> Pierre-Luc
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 19, 2014 at 11:16 AM, Min Chen <mi...@citrix.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I would rather CI be considered together with this thread, since
>>>>>>>this
>>>>>>> thread needs to decide at what condition RM can merge a
>>>>>>>hotfix/bugfic
>>>>>>> branch to release branch.
>>>>>>>
>>>>>>> Thanks
>>>>>>> -min
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>> On Aug 19, 2014, at 8:09 AM, "Pierre-Luc Dion"
>>>>>>>><pd...@cloudops.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> +1 ,  CI shouldn't be another topic?
>>>>>>>>
>>>>>>>> What is required or missing to have CI in place?
>>>>>>>>
>>>>>>>>
>>>>>>>> *Pierre-Luc DION*
>>>>>>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>>>>>>> t 855.652.5683
>>>>>>>>
>>>>>>>> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions
>>>>>>>>Experts
>>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>>>>>> w cloudops.com *|* tw @CloudOps_
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav
>>>>>>>> <ro...@shapeblue.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen
>>>>>>>>>><ru...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>> Say you grab a patch from review board and stick it in a hotfix
>>>>>>>>>> branch,
>>>>>>>>> test that Šcall for merge on release branch.
>>>>>>>>>> Do we *merge* to master or can we apply the patch directly to
>>>>>>>>>> master
>>>>>>>>> (git am -sŠ) ?
>>>>>>>>>
>>>>>>>>> Once the hotfix branch is merged on release branch, we would
>>>>>>>>>merge
>>>>>>>>> the
>>>>>>>>> release branch to master, that will bring the hotfix on master as
>>>>>>>>> well.
>>>>>>>>>
>>>>>>>>> We don¹t want to encourage working on master for fixes that
>>>>>>>>>qualify
>>>>>>>>> for
>>>>>>>>> release branches directly so ideally we should not git am -s the
>>>>>>>>> patch
>>>>>>> on
>>>>>>>>> master. But there is scope for non-strictness for a situation
>>>>>>>>> needing
>>>>>>> git
>>>>>>>>> am -s <patch> on master directly, it would be at the discretion
>>>>>>>>>of
>>>>>>>>> the
>>>>>>> RM
>>>>>>>>> and committers.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>
>>>>>
>>>>> 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.
>>>
>>> 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.
>>
>
>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: [VOTE] Adapting git workflow for release branches

[Sebastien Goasguen <ru...@gmail.com>]

On Aug 20, 2014, at 12:52 PM, Rohit Yadav <ro...@shapeblue.com> wrote:

> Hi all,
> 
> Thanks for participating. After 120 hours or 5 days, the voting result for the proposal is as follows:
> 
> +1 (PMC / binding)
> none
> 
> +1 (non binding)
> 6 people
> 
> 0
> none
> 
> -1 (PMC / binding)
> 1 person
> 
> -1 (non binding)
> 3 people
> 
> We don’t have a consensus/majority or a veto as per our bylaws; and the negative voters did not try to explain the deficiencies and raise issues in proposed agenda but their concerns were around valid broader issues of gate keeping, code quality and CI, and the common argument was to address those issues first.
> 
> My personal opinion is that adopting the proposed changes will not change, affect or conflict with a CI/code quality solution that the community needs and will adopt in future. That said, it will be only peaceful and agreeable to re-propose the voting agenda again in future and get community consensus.
> 
> I would also welcome our PMC’s advise on this situation.

With my PMC hat on I applaud you for trying to reach consensus, make a proposal and try to explain everything.

I agree that we need consensus that unfortunately we don't seem to have.

So the onus is now on the folks who voted -1 to try to move us forward.

> 
> 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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

Hi Daan and Sebastien,

Thank you for your inputs.

I did not vote as I wanted to have a positive consensus before I vote for my own proposal just to add to the counter or satisfy my ego. I understand that the gavel is with our PMC but I would still want us to try if we can meet half way, improve with small steps and have some sort of agreement.

Regards.

On 20-Aug-2014, at 8:41 pm, Daan Hoogland <da...@gmail.com> wrote:

> Rohit,
>
> I don't see your count. At least Wido and I have voted +1 so that would be
> +2 from the PMC. But the vote is a communitee vote. It is about techinique
> not process is it. If not then non binding votes are merely for information
> and only PMC votes are counted.
>
> In cases like these I think either full concensus or anarchy are the only
> options.
>
> I must say that I am very dissappointed by the idea that we must have a
> full solution according to some instead of taking steps towards it. This
> wouold have been a good step. I for one will not tolerate a -forward thread
> anymore for any release I am responsible for. It has cost me to much time
> in searching for the source of conflicts. Anarchy from my side until we
> find some consensus!
>
> regards,
>
>
> On Wed, Aug 20, 2014 at 6:52 PM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
>
>> Hi all,
>>
>> Thanks for participating. After 120 hours or 5 days, the voting result for
>> the proposal is as follows:
>>
>> +1 (PMC / binding)
>> none
>>
>> +1 (non binding)
>> 6 people
>>
>> 0
>> none
>>
>> -1 (PMC / binding)
>> 1 person
>>
>> -1 (non binding)
>> 3 people
>>
>> We don’t have a consensus/majority or a veto as per our bylaws; and the
>> negative voters did not try to explain the deficiencies and raise issues in
>> proposed agenda but their concerns were around valid broader issues of gate
>> keeping, code quality and CI, and the common argument was to address those
>> issues first.
>>
>> My personal opinion is that adopting the proposed changes will not change,
>> affect or conflict with a CI/code quality solution that the community needs
>> and will adopt in future. That said, it will be only peaceful and agreeable
>> to re-propose the voting agenda again in future and get community consensus.
>>
>> I would also welcome our PMC’s advise on this situation.
>>
>> 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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

Edison buddy,

On 21-Aug-2014, at 1:11 am, Edison Su <Ed...@citrix.com> wrote:
> If you think I am not a good PMC members, you can start a vote to kick me out, if that's something you want.

You’re taking this the wrong way, it would be immature and unprofessional to take any severe action for petty disagreements. I tried to peacefully end this voting thread only to get more opinions and arguments I did not ask for.

I’ve surrendered already, peace.

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: [VOTE] Adapting git workflow for release branches

[John Kinsella <jl...@stratosec.co>]

Let’s keep this civil, folks.

RE: [VOTE] Adapting git workflow for release branches

[Edison Su <Ed...@citrix.com>]

> -----Original Message-----
> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> Sent: Wednesday, August 20, 2014 3:59 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Adapting git workflow for release branches
> 
> 
> On 20-Aug-2014, at 10:33 pm, Edison Su <Ed...@citrix.com> wrote:
> 
> > There are several proposals from Citrix:
> > http://markmail.org/thread/c4pded5i3r22keqw
> > http://markmail.org/thread/xoyjw2sduenlytwm
> 
> Ahem ahem, what Sebastien said. Edison, we have more expectations from
> PMC members :)
If you think I am not a good PMC members, you can start a vote to kick me out, if that's something you want.

> 
> Thanks to Citrix for donating CloudStack to Apache, donating infra, human
> resources, helping with events etc. No one disagrees, but the fact is Citrix
> does not "own" the community or Apache CloudStack or its contributors; or
> drive its development or releases. Doing this or trying to do so won't be good
> for an opensource project, its community, its adoption or its impact.
> 
> I raised such an issue among others in a recent thread and I'm still waiting for
> a reply:
> http://markmail.org/message/t3gskzrsd3jmw2zx
> 
> Those who sent negative votes, few of them added other Citrix folks in cc
> which felt like lobbying/bullying, it was more painful to read -1 me too emails
> with no relevant reasons from the cc'ed persons afterwards and all of them
> came allegedly came from Citrix's SC/US office (allegedly local effect?).
> 
> This way of thinking and working is not healthy for the project and its
> community. So kindly stop, please wear your Apache hat when you are on
> the ML as an individual.


I do acting as individual, you don't need teach me about it. We all both want to get Apache CloudStack on the
Right track. I think I do have valid argument points, I think we can have different opinion on how the thing will work.


> 
> > Citrix also donates real hardware for CI.
> > We don't lack of proposals to solve these issues, it's community has
> > different opinions On how to solve these issues, or don't solve these issues
> at all.
> > Going forward, we need to have consensus on we have to solve these
> > issues before we start another
> > release:http://markmail.org/thread/ofalvk4uhejtffpg
> 
> For starters can you start a fresh discussion thread with a suitable subject.
> 
> The way things works is that first you start a [DISCUSS] discussion thread if
> you don't know what needs to be done, but if you know what needs to be
> done you start a [PROPOSAL] thread. Next, once you've gathered concrete
> actionable items and a vibe that voting needs to be done, you start a [VOTE]
> thread. Finally, if it voting passes you go ahead and implement the actionable
> items.
I will, I already said in other threads. Thanks for the education.

> 
> 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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

On 20-Aug-2014, at 10:33 pm, Edison Su <Ed...@citrix.com> wrote:

> There are several proposals from Citrix:
> http://markmail.org/thread/c4pded5i3r22keqw
> http://markmail.org/thread/xoyjw2sduenlytwm

Ahem ahem, what Sebastien said. Edison, we have more expectations from PMC members :)

Thanks to Citrix for donating CloudStack to Apache, donating infra, human resources, helping with events etc. No one disagrees, but the fact is Citrix does not “own” the community or Apache CloudStack or its contributors; or drive its development or releases. Doing this or trying to do so won’t be good for an opensource project, its community, its adoption or its impact.

I raised such an issue among others in a recent thread and I'm still waiting for a reply:
http://markmail.org/message/t3gskzrsd3jmw2zx

Those who sent negative votes, few of them added other Citrix folks in cc which felt like lobbying/bullying, it was more painful to read -1 me too emails with no relevant reasons from the cc’ed persons afterwards and all of them came allegedly came from Citrix’s SC/US office (allegedly local effect?).

This way of thinking and working is not healthy for the project and its community. So kindly stop, please wear your Apache hat when you are on the ML as an individual.

> Citrix also donates real hardware for CI.
> We don't lack of proposals to solve these issues, it's community has different opinions
> On how to solve these issues, or don't solve these issues at all.
> Going forward, we need to have consensus on we have to solve these issues before we start another release:http://markmail.org/thread/ofalvk4uhejtffpg

For starters can you start a fresh discussion thread with a suitable subject.

The way things works is that first you start a [DISCUSS] discussion thread if you don’t know what needs to be done, but if you know what needs to be done you start a [PROPOSAL] thread. Next, once you’ve gathered concrete actionable items and a vibe that voting needs to be done, you start a [VOTE] thread. Finally, if it voting passes you go ahead and implement the actionable items.

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: [VOTE] Adapting git workflow for release branches

[Edison Su <Ed...@citrix.com>]

> -----Original Message-----
> From: Erik Weber [mailto:terbolous@gmail.com]
> Sent: Wednesday, August 20, 2014 3:15 PM
> To: dev
> Subject: Re: [VOTE] Adapting git workflow for release branches
> 
> >
> >
> > > > There are several proposals from Citrix:
> > > > http://markmail.org/thread/c4pded5i3r22keqw
> > > > http://markmail.org/thread/xoyjw2sduenlytwm
> > >
> > > Edison, Citrix can't make proposals. Individuals do..
> > Sorry, what I am trying to say is "from people, who happen to be
> > employee from Citrix".
> >
> > > I know Citrix has an internal BVT/CI whatever you want to call it
> > system, but
> > > until it is live for the whole community I don't think there is any
> > point of
> > > discussing it.
> > >
> > > There is hardware being donated (which people on this list may not
> > > be
> > aware
> > > off), but it is not available yet, nor do we know how this hardware
> > > will
> > be
> > > managed.
> > > So right now the only apache infra we have to do CI is the current
> > jenkins
> > > setup and things like TravisCI which I have mentioned before.
> > >
> > > In any case, the threads you mention did not reach consensus or led
> > > to a vote thread. The way forward is to keep working on those
> > > threads or
> > start a
> > > VOTE thread.
> > >
> > > I am just wondering what we will VOTE on in terms of CI, since there
> > > is
> > no
> > > infra to do it yet and nobody seems to be owning this (or maybe I
> > > missed some threads).
> >
> > Ok, I got it. So right now, we don't have problem about need to have
> > CI or not, It's about how will gonna do it, right?
> > The options we have today:
> > 1.TravisCi,
> > 2. the CI donated from Citrix(I heard of that the donated hardware is
> > delayed, I mistakenly thought the hardware is already donated), 3. any
> > other hardware( I am working on a machine created on DigitalOcean,
> > $80/month, 8G memory, 4 core cpus, SSD, I want to donate it as CI
> > machine personally, if there is no other good solution) Any other
> > options?
> >
> 
> Regarding nr. 3) if hardware really is/was the issue, I'm sure there's several
> cloudstack users that would happily donate a VM or two.
> Atleast I know that I've seen several offerings, and I can say that my
> employer most likely would be able to donate additional hardware if
> necessary.
Yes, I think hardware and how to manage hardware is really an issue. If there are donation on the 
Hardware, that will be great. 
 
> 
> The problem is that there's not really any system/routine available to take it
> into use, ie. the "CI/BVT" we're discussing is currently an internal Citrix thing,
> not a community thing.
CI/BVT has three parts:
1. The test framework. Currently, it's Marvin, it's open sourced since beginning.
2. The test cases, some of them are open sourced, some are not. The open sourced test cases can cover basic functionality.
3. The test infrastructure: e.g. how to install hypervisors, how to manage IP address assigned to hypervisors etc. This part, Citrix has
Some python/shell scripts to manage these, not sure the status of these code, maybe open sourced somewhere. I think it's not the only way to manage hardware, 
Don't need to depend on Citrix's code.

So we need hardware and a layer to manage these hardware.


> 
> --
> Erik

Re: [VOTE] Adapting git workflow for release branches

[Erik Weber <te...@gmail.com>]

>
>
> > > There are several proposals from Citrix:
> > > http://markmail.org/thread/c4pded5i3r22keqw
> > > http://markmail.org/thread/xoyjw2sduenlytwm
> >
> > Edison, Citrix can't make proposals. Individuals do..
> Sorry, what I am trying to say is "from people, who happen to be employee
> from Citrix".
>
> > I know Citrix has an internal BVT/CI whatever you want to call it
> system, but
> > until it is live for the whole community I don't think there is any
> point of
> > discussing it.
> >
> > There is hardware being donated (which people on this list may not be
> aware
> > off), but it is not available yet, nor do we know how this hardware will
> be
> > managed.
> > So right now the only apache infra we have to do CI is the current
> jenkins
> > setup and things like TravisCI which I have mentioned before.
> >
> > In any case, the threads you mention did not reach consensus or led to a
> > vote thread. The way forward is to keep working on those threads or
> start a
> > VOTE thread.
> >
> > I am just wondering what we will VOTE on in terms of CI, since there is
> no
> > infra to do it yet and nobody seems to be owning this (or maybe I missed
> > some threads).
>
> Ok, I got it. So right now, we don't have problem about need to have CI or
> not,
> It's about how will gonna do it, right?
> The options we have today:
> 1.TravisCi,
> 2. the CI donated from Citrix(I heard of that the donated hardware is
> delayed, I mistakenly thought the hardware is already donated),
> 3. any other hardware( I am working on a machine created on DigitalOcean,
> $80/month, 8G memory, 4 core cpus, SSD, I want to donate it as CI machine
> personally, if there is no other good solution)
> Any other options?
>

Regarding nr. 3) if hardware really is/was the issue, I'm sure there's
several cloudstack users that would happily donate a VM or two.
Atleast I know that I've seen several offerings, and I can say that my
employer most likely would be able to donate additional hardware if
necessary.

The problem is that there's not really any system/routine available to take
it into use, ie. the "CI/BVT" we're discussing is currently an internal
Citrix thing, not a community thing.

-- 
Erik

RE: [VOTE] Adapting git workflow for release branches

[Edison Su <Ed...@citrix.com>]

> -----Original Message-----
> From: Sebastien Goasguen [mailto:runseb@gmail.com]
> Sent: Wednesday, August 20, 2014 1:47 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Adapting git workflow for release branches
> 
> 
> On Aug 20, 2014, at 4:33 PM, Edison Su <Ed...@citrix.com> wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> >> Sent: Wednesday, August 20, 2014 1:17 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: [VOTE] Adapting git workflow for release branches
> >>
> >>
> >> On 20-Aug-2014, at 9:55 pm, Edison Su <Ed...@citrix.com> wrote:
> >>> Maybe I need to reiterate why I reject the proposal for now, as I am
> >>> the
> >> only person vote -1(binding).
> >>> I think we all understand the pain as a release manager, even right
> >>> after 4.2 release, I asked community to think about how We gonna fix
> >>> the
> >> release procedure(http://markmail.org/message/3bptkm2xyrai6i7m), no
> >> much response at that time.
> >>> But the situation is much better now, as more and more people are
> >>> trying
> >> to solve the problem, instead of staying on the status quo.
> >>> To me, the highest priority issue we need to solve is the CI, even a
> >>> simple
> >> CI against simulator, will catch a lot of regressions in management
> >> server code.
> >>> The second priority, is code review.
> >>> The git flow co-relates to how we gonna solve above two issues. I
> >>> think that's the different opinions we have today, and I already
> >>> made the point that If we choose different ways to solve the above
> >>> two issues, we may choose different git flow:
> >>> http://markmail.org/message/hyk54z7imn5gyqkn
> >>> So can't we just put our efforts to solve the big problems at first,
> >>> instead of
> >> debating on the small things forever?
> >>
> >> I surrender (and this proposal), but I would still like to see
> >> something actionable on the "big" problems from your side like why
> >> don't you start a proposal/discussion around it? Let's solve the biggies first.
> >
> > There are several proposals from Citrix:
> > http://markmail.org/thread/c4pded5i3r22keqw
> > http://markmail.org/thread/xoyjw2sduenlytwm
> 
> Edison, Citrix can't make proposals. Individuals do..
Sorry, what I am trying to say is "from people, who happen to be employee from Citrix".

> I know Citrix has an internal BVT/CI whatever you want to call it system, but
> until it is live for the whole community I don't think there is any point of
> discussing it.
> 
> There is hardware being donated (which people on this list may not be aware
> off), but it is not available yet, nor do we know how this hardware will be
> managed.
> So right now the only apache infra we have to do CI is the current jenkins
> setup and things like TravisCI which I have mentioned before.
> 
> In any case, the threads you mention did not reach consensus or led to a
> vote thread. The way forward is to keep working on those threads or start a
> VOTE thread.
> 
> I am just wondering what we will VOTE on in terms of CI, since there is no
> infra to do it yet and nobody seems to be owning this (or maybe I missed
> some threads).

Ok, I got it. So right now, we don't have problem about need to have CI or not,
It's about how will gonna do it, right?
The options we have today:
1.TravisCi, 
2. the CI donated from Citrix(I heard of that the donated hardware is delayed, I mistakenly thought the hardware is already donated), 
3. any other hardware( I am working on a machine created on DigitalOcean, $80/month, 8G memory, 4 core cpus, SSD, I want to donate it as CI machine personally, if there is no other good solution)
Any other options?

> 
> -sebastien
> 
> > Citrix also donates real hardware for CI.
> > We don't lack of proposals to solve these issues, it's community has
> > different opinions On how to solve these issues, or don't solve these issues
> at all.
> > Going forward, we need to have consensus on we have to solve these
> > issues before we start another release:
> > http://markmail.org/thread/ofalvk4uhejtffpg
> >
> >>
> >> Edison the things I was trying to bring IMO won't conflict with any
> >> future CI/code review process that we may adopt, they focus on how we
> >> can improve community participation and do (multiple) releases &
> >> commit maintenance across branches.
> >>
> >> 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: [VOTE] Adapting git workflow for release branches

[Edison Su <Ed...@citrix.com>]

Sent from my Windows Phone
________________________________
From: Sebastien Goasguen<ma...@gmail.com>
Sent: ‎8/‎20/‎2014 1:47 PM
To: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>
Subject: Re: [VOTE] Adapting git workflow for release branches


On Aug 20, 2014, at 4:33 PM, Edison Su <Ed...@citrix.com> wrote:

>
>
>> -----Original Message-----
>> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
>> Sent: Wednesday, August 20, 2014 1:17 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] Adapting git workflow for release branches
>>
>>
>> On 20-Aug-2014, at 9:55 pm, Edison Su <Ed...@citrix.com> wrote:
>>> Maybe I need to reiterate why I reject the proposal for now, as I am the
>> only person vote -1(binding).
>>> I think we all understand the pain as a release manager, even right
>>> after 4.2 release, I asked community to think about how We gonna fix the
>> release procedure(http://markmail.org/message/3bptkm2xyrai6i7m), no
>> much response at that time.
>>> But the situation is much better now, as more and more people are trying
>> to solve the problem, instead of staying on the status quo.
>>> To me, the highest priority issue we need to solve is the CI, even a simple
>> CI against simulator, will catch a lot of regressions in management server
>> code.
>>> The second priority, is code review.
>>> The git flow co-relates to how we gonna solve above two issues. I
>>> think that's the different opinions we have today, and I already made
>>> the point that If we choose different ways to solve the above two
>>> issues, we may choose different git flow:
>>> http://markmail.org/message/hyk54z7imn5gyqkn
>>> So can't we just put our efforts to solve the big problems at first, instead of
>> debating on the small things forever?
>>
>> I surrender (and this proposal), but I would still like to see something
>> actionable on the "big" problems from your side like why don't you start a
>> proposal/discussion around it? Let's solve the biggies first.
>
> There are several proposals from Citrix:
> http://markmail.org/thread/c4pded5i3r22keqw
> http://markmail.org/thread/xoyjw2sduenlytwm

Edison, Citrix can't make proposals. Individuals do..
I know Citrix has an internal BVT/CI whatever you want to call it system, but until it is live for the whole community I don't think there is any point of discussing it.

There is hardware being donated (which people on this list may not be aware off), but it is not available yet, nor do we know how this hardware will be managed.
So right now the only apache infra we have to do CI is the current jenkins setup and things like TravisCI which I have mentioned before.

In any case, the threads you mention did not reach consensus or led to a vote thread. The way forward is to keep working on those threads or start a VOTE thread.

I am just wondering what we will VOTE on in terms of CI, since there is no infra to do it yet and nobody seems to be owning this (or maybe I missed some threads).

-sebastien

> Citrix also donates real hardware for CI.
> We don't lack of proposals to solve these issues, it's community has different opinions
> On how to solve these issues, or don't solve these issues at all.
> Going forward, we need to have consensus on we have to solve these issues before we start another release: http://markmail.org/thread/ofalvk4uhejtffpg
>
>>
>> Edison the things I was trying to bring IMO won't conflict with any future
>> CI/code review process that we may adopt, they focus on how we can
>> improve community participation and do (multiple) releases & commit
>> maintenance across branches.
>>
>> 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: [VOTE] Adapting git workflow for release branches

[Sebastien Goasguen <ru...@gmail.com>]

On Aug 20, 2014, at 4:33 PM, Edison Su <Ed...@citrix.com> wrote:

> 
> 
>> -----Original Message-----
>> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
>> Sent: Wednesday, August 20, 2014 1:17 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] Adapting git workflow for release branches
>> 
>> 
>> On 20-Aug-2014, at 9:55 pm, Edison Su <Ed...@citrix.com> wrote:
>>> Maybe I need to reiterate why I reject the proposal for now, as I am the
>> only person vote -1(binding).
>>> I think we all understand the pain as a release manager, even right
>>> after 4.2 release, I asked community to think about how We gonna fix the
>> release procedure(http://markmail.org/message/3bptkm2xyrai6i7m), no
>> much response at that time.
>>> But the situation is much better now, as more and more people are trying
>> to solve the problem, instead of staying on the status quo.
>>> To me, the highest priority issue we need to solve is the CI, even a simple
>> CI against simulator, will catch a lot of regressions in management server
>> code.
>>> The second priority, is code review.
>>> The git flow co-relates to how we gonna solve above two issues. I
>>> think that's the different opinions we have today, and I already made
>>> the point that If we choose different ways to solve the above two
>>> issues, we may choose different git flow:
>>> http://markmail.org/message/hyk54z7imn5gyqkn
>>> So can't we just put our efforts to solve the big problems at first, instead of
>> debating on the small things forever?
>> 
>> I surrender (and this proposal), but I would still like to see something
>> actionable on the "big" problems from your side like why don't you start a
>> proposal/discussion around it? Let's solve the biggies first.
> 
> There are several proposals from Citrix:
> http://markmail.org/thread/c4pded5i3r22keqw
> http://markmail.org/thread/xoyjw2sduenlytwm

Edison, Citrix can't make proposals. Individuals do..
I know Citrix has an internal BVT/CI whatever you want to call it system, but until it is live for the whole community I don't think there is any point of discussing it.

There is hardware being donated (which people on this list may not be aware off), but it is not available yet, nor do we know how this hardware will be managed.
So right now the only apache infra we have to do CI is the current jenkins setup and things like TravisCI which I have mentioned before.

In any case, the threads you mention did not reach consensus or led to a vote thread. The way forward is to keep working on those threads or start a VOTE thread.

I am just wondering what we will VOTE on in terms of CI, since there is no infra to do it yet and nobody seems to be owning this (or maybe I missed some threads).

-sebastien

> Citrix also donates real hardware for CI.
> We don't lack of proposals to solve these issues, it's community has different opinions
> On how to solve these issues, or don't solve these issues at all.
> Going forward, we need to have consensus on we have to solve these issues before we start another release: http://markmail.org/thread/ofalvk4uhejtffpg
> 
>> 
>> Edison the things I was trying to bring IMO won't conflict with any future
>> CI/code review process that we may adopt, they focus on how we can
>> improve community participation and do (multiple) releases & commit
>> maintenance across branches.
>> 
>> 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: [VOTE] Adapting git workflow for release branches

[Edison Su <Ed...@citrix.com>]

> -----Original Message-----
> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> Sent: Wednesday, August 20, 2014 1:17 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Adapting git workflow for release branches
> 
> 
> On 20-Aug-2014, at 9:55 pm, Edison Su <Ed...@citrix.com> wrote:
> > Maybe I need to reiterate why I reject the proposal for now, as I am the
> only person vote -1(binding).
> > I think we all understand the pain as a release manager, even right
> > after 4.2 release, I asked community to think about how We gonna fix the
> release procedure(http://markmail.org/message/3bptkm2xyrai6i7m), no
> much response at that time.
> > But the situation is much better now, as more and more people are trying
> to solve the problem, instead of staying on the status quo.
> > To me, the highest priority issue we need to solve is the CI, even a simple
> CI against simulator, will catch a lot of regressions in management server
> code.
> > The second priority, is code review.
> > The git flow co-relates to how we gonna solve above two issues. I
> > think that's the different opinions we have today, and I already made
> > the point that If we choose different ways to solve the above two
> > issues, we may choose different git flow:
> > http://markmail.org/message/hyk54z7imn5gyqkn
> > So can't we just put our efforts to solve the big problems at first, instead of
> debating on the small things forever?
> 
> I surrender (and this proposal), but I would still like to see something
> actionable on the "big" problems from your side like why don't you start a
> proposal/discussion around it? Let's solve the biggies first.

There are several proposals from Citrix:
http://markmail.org/thread/c4pded5i3r22keqw
http://markmail.org/thread/xoyjw2sduenlytwm
Citrix also donates real hardware for CI.
We don't lack of proposals to solve these issues, it's community has different opinions
On how to solve these issues, or don't solve these issues at all.
Going forward, we need to have consensus on we have to solve these issues before we start another release: http://markmail.org/thread/ofalvk4uhejtffpg
   
> 
> Edison the things I was trying to bring IMO won't conflict with any future
> CI/code review process that we may adopt, they focus on how we can
> improve community participation and do (multiple) releases & commit
> maintenance across branches.
> 
> 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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

On 20-Aug-2014, at 9:55 pm, Edison Su <Ed...@citrix.com> wrote:
> Maybe I need to reiterate why I reject the proposal for now, as I am the only person vote -1(binding).
> I think we all understand the pain as a release manager, even right after 4.2 release, I asked community to think about how
> We gonna fix the release procedure(http://markmail.org/message/3bptkm2xyrai6i7m), no much response at that time.
> But the situation is much better now, as more and more people are trying to solve the problem, instead of staying on the status quo.
> To me, the highest priority issue we need to solve is the CI, even a simple CI against simulator, will catch a lot of regressions in management server code.
> The second priority, is code review.
> The git flow co-relates to how we gonna solve above two issues. I think that's the different opinions we have today, and I already made the point that
> If we choose different ways to solve the above two issues, we may choose different git flow: http://markmail.org/message/hyk54z7imn5gyqkn
> So can't we just put our efforts to solve the big problems at first, instead of debating on the small things forever?

I surrender (and this proposal), but I would still like to see something actionable on the “big” problems from your side like why don’t you start a proposal/discussion around it? Let’s solve the biggies first.

Edison the things I was trying to bring IMO won’t conflict with any future CI/code review process that we may adopt, they focus on how we can improve community participation and do (multiple) releases & commit maintenance across branches.

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: [VOTE] Adapting git workflow for release branches

[Edison Su <Ed...@citrix.com>]

> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Wednesday, August 20, 2014 11:42 AM
> To: dev
> Subject: Re: [VOTE] Adapting git workflow for release branches
> 
> Rohit,
> 
> I don't see your count. At least Wido and I have voted +1 so that would be
> +2 from the PMC. But the vote is a communitee vote. It is about
> +techinique
> not process is it. If not then non binding votes are merely for information and
> only PMC votes are counted.
> 
> In cases like these I think either full concensus or anarchy are the only
> options.
> 
> I must say that I am very dissappointed by the idea that we must have a full
> solution according to some instead of taking steps towards it. This wouold
> have been a good step. I for one will not tolerate a -forward thread anymore
> for any release I am responsible for. It has cost me to much time in searching
> for the source of conflicts. Anarchy from my side until we find some
> consensus!

Maybe I need to reiterate why I reject the proposal for now, as I am the only person vote -1(binding).
I think we all understand the pain as a release manager, even right after 4.2 release, I asked community to think about how
We gonna fix the release procedure(http://markmail.org/message/3bptkm2xyrai6i7m), no much response at that time. 
But the situation is much better now, as more and more people are trying to solve the problem, instead of staying on the status quo.
To me, the highest priority issue we need to solve is the CI, even a simple CI against simulator, will catch a lot of regressions in management server code.
The second priority, is code review. 
The git flow co-relates to how we gonna solve above two issues. I think that's the different opinions we have today, and I already made the point that 
If we choose different ways to solve the above two issues, we may choose different git flow: http://markmail.org/message/hyk54z7imn5gyqkn
So can't we just put our efforts to solve the big problems at first, instead of debating on the small things forever?

> 
> regards,
> 
> 
> On Wed, Aug 20, 2014 at 6:52 PM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
> 
> > Hi all,
> >
> > Thanks for participating. After 120 hours or 5 days, the voting result
> > for the proposal is as follows:
> >
> > +1 (PMC / binding)
> > none
> >
> > +1 (non binding)
> > 6 people
> >
> > 0
> > none
> >
> > -1 (PMC / binding)
> > 1 person
> >
> > -1 (non binding)
> > 3 people
> >
> > We don’t have a consensus/majority or a veto as per our bylaws; and
> > the negative voters did not try to explain the deficiencies and raise
> > issues in proposed agenda but their concerns were around valid broader
> > issues of gate keeping, code quality and CI, and the common argument
> > was to address those issues first.
> >
> > My personal opinion is that adopting the proposed changes will not
> > change, affect or conflict with a CI/code quality solution that the
> > community needs and will adopt in future. That said, it will be only
> > peaceful and agreeable to re-propose the voting agenda again in future
> and get community consensus.
> >
> > I would also welcome our PMC’s advise on this situation.
> >
> > 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: [VOTE] Adapting git workflow for release branches

[Daan Hoogland <da...@gmail.com>]

Rohit,

I don't see your count. At least Wido and I have voted +1 so that would be
+2 from the PMC. But the vote is a communitee vote. It is about techinique
not process is it. If not then non binding votes are merely for information
and only PMC votes are counted.

In cases like these I think either full concensus or anarchy are the only
options.

I must say that I am very dissappointed by the idea that we must have a
full solution according to some instead of taking steps towards it. This
wouold have been a good step. I for one will not tolerate a -forward thread
anymore for any release I am responsible for. It has cost me to much time
in searching for the source of conflicts. Anarchy from my side until we
find some consensus!

regards,


On Wed, Aug 20, 2014 at 6:52 PM, Rohit Yadav <ro...@shapeblue.com>
wrote:

> Hi all,
>
> Thanks for participating. After 120 hours or 5 days, the voting result for
> the proposal is as follows:
>
> +1 (PMC / binding)
> none
>
> +1 (non binding)
> 6 people
>
> 0
> none
>
> -1 (PMC / binding)
> 1 person
>
> -1 (non binding)
> 3 people
>
> We don’t have a consensus/majority or a veto as per our bylaws; and the
> negative voters did not try to explain the deficiencies and raise issues in
> proposed agenda but their concerns were around valid broader issues of gate
> keeping, code quality and CI, and the common argument was to address those
> issues first.
>
> My personal opinion is that adopting the proposed changes will not change,
> affect or conflict with a CI/code quality solution that the community needs
> and will adopt in future. That said, it will be only peaceful and agreeable
> to re-propose the voting agenda again in future and get community consensus.
>
> I would also welcome our PMC’s advise on this situation.
>
> 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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

On 20-Aug-2014, at 7:03 pm, Sudha Ponnaganti <su...@citrix.com> wrote:
> Why not address CI and Quality standards that came up in the discussions and get them out of the way first and then address gitflow as a second step. Looks like majority consensus is in that direction. Now CI is available, seem to be easy to implement as proposal has been done by Alex. Looks like  80-90% of pieces are in place. Just need community agreement.

People have voted, this thread is over now and we’re not proceeding with the agenda. What’s your point now?

meh, https://www.youtube.com/watch?v=-F-3E8pyjFo

>
> Thanks
> /Sudha
>
> -----Original Message-----
> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> Sent: Wednesday, August 20, 2014 9:52 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Adapting git workflow for release branches
>
> Hi all,
>
> Thanks for participating. After 120 hours or 5 days, the voting result for the proposal is as follows:
>
> +1 (PMC / binding)
> none
>
> +1 (non binding)
> 6 people
>
> 0
> none
>
> -1 (PMC / binding)
> 1 person
>
> -1 (non binding)
> 3 people
>
> We don't have a consensus/majority or a veto as per our bylaws; and the negative voters did not try to explain the deficiencies and raise issues in proposed agenda but their concerns were around valid broader issues of gate keeping, code quality and CI, and the common argument was to address those issues first.
>
> My personal opinion is that adopting the proposed changes will not change, affect or conflict with a CI/code quality solution that the community needs and will adopt in future. That said, it will be only peaceful and agreeable to re-propose the voting agenda again in future and get community consensus.
>
> I would also welcome our PMC's advise on this situation.
>
> 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.

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: [VOTE] Adapting git workflow for release branches

[Sudha Ponnaganti <su...@citrix.com>]

Why not address CI and Quality standards that came up in the discussions and get them out of the way first and then address gitflow as a second step. Looks like majority consensus is in that direction. Now CI is available, seem to be easy to implement as proposal has been done by Alex. Looks like  80-90% of pieces are in place. Just need community agreement. 

Thanks
/Sudha

-----Original Message-----
From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com] 
Sent: Wednesday, August 20, 2014 9:52 AM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Adapting git workflow for release branches

Hi all,

Thanks for participating. After 120 hours or 5 days, the voting result for the proposal is as follows:

+1 (PMC / binding)
none

+1 (non binding)
6 people

0
none

-1 (PMC / binding)
1 person

-1 (non binding)
3 people

We don't have a consensus/majority or a veto as per our bylaws; and the negative voters did not try to explain the deficiencies and raise issues in proposed agenda but their concerns were around valid broader issues of gate keeping, code quality and CI, and the common argument was to address those issues first.

My personal opinion is that adopting the proposed changes will not change, affect or conflict with a CI/code quality solution that the community needs and will adopt in future. That said, it will be only peaceful and agreeable to re-propose the voting agenda again in future and get community consensus.

I would also welcome our PMC's advise on this situation.

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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

Hi all,

Thanks for participating. After 120 hours or 5 days, the voting result for the proposal is as follows:

+1 (PMC / binding)
none

+1 (non binding)
6 people

0
none

-1 (PMC / binding)
1 person

-1 (non binding)
3 people

We don’t have a consensus/majority or a veto as per our bylaws; and the negative voters did not try to explain the deficiencies and raise issues in proposed agenda but their concerns were around valid broader issues of gate keeping, code quality and CI, and the common argument was to address those issues first.

My personal opinion is that adopting the proposed changes will not change, affect or conflict with a CI/code quality solution that the community needs and will adopt in future. That said, it will be only peaceful and agreeable to re-propose the voting agenda again in future and get community consensus.

I would also welcome our PMC’s advise on this situation.

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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

On 19-Aug-2014, at 8:11 pm, Min Chen <mi...@citrix.com> wrote:

> I personally don't think introducing CI or gerrit or github pull request
> will take away a committer's privilege to commit. If you are a stakeholder
> who really care about your product, you will not be scared away by this
> extra enforcement, this will actually make our cloudstack ecosystem better
> and healthier, and will also benefit other contributors in the same
> community. To me, this is not a punishment per se, your code is just not

I’ve a lot of concerns around this, raised on another thread in a reply to David’s email.

I don’t see many committers go and help with the reviews on our current reviewboard.
If we start having code reviews on gerrit, github or what have you, will they share the fate as reviews on our reviewboard?

> directly committed in, and you can enhance it and commit later. We are not
> even requesting for bug-free code, I know, that is not possible in
> software world, but at least we should have some stableness in our code to
> not block other peers. As far as I know, Linux has much better control
> about what patch to be pulled in, which makes it much more stabler than
> us. As for your traffic example, at least there we have DMV road test,
> traffic light, traffic patrol infrastructure to have basic guard.
> CI/gerrit are just like those basic enforcement infrastructure for
> CloudStack development process.

How do you propose we solve the wait/timelines issue?

> I don't want this to become a two-person argument forever. I already
> clearly explained my ideas and takes on this. Let's hear others.

This is not supposed to be a discussion thread. The place for other ideas is in another proposal thread.

Any vote is acceptable as long as it can share a reason (good or bad) with the “proposed” agenda only.

So, let me try this again and humbly ask again — what is wrong in the proposed items and how do they make the current workflow worse? Better, if you can share a solution that has to do with the “agenda” only.

Cheers.

>
> Thanks
> -min
>
> On 8/19/14 10:55 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>
>> tl;dr? hope you read it;
>>
>> On 19-Aug-2014, at 7:10 pm, Min Chen <mi...@citrix.com> wrote:
>>
>>> I will hesitate on this "No enforcement" approach in the flow. I bet
>>> that
>>> without some kind of enforcement, based on past experience, after one
>>
>> Stakeholder will always care. The system should be optimistic to allow
>> things in and not to punish in advance.
>> That’s how many scalable opensource project such as Linux, Firefox and
>> our own Apache works (people over code that is).
>>
>> If you’ve any ideas please share. We’ve to find a “non-strict”
>> enforcement to get best of all things and I don’t have a solution right
>> now to suggest.
>>
>> “Strict enforcement” won’t be scalable anyway, hackers always find way
>> around gaming the system.
>>
>> Unicorns, Santas and bug-less code perhaps don’t exist IMHO so may never
>> guarantee code quality but only improve over time. Even things like
>> pacemakers, realtime systems used in mining, surgery, aerospace, mars
>> rover etc; openssl (heartbleed) have bugs and issues. This is not to say
>> that we should not have code reviews, other processes and automated
>> build/CI/smoke-tests are “not” needed, they are needed but they “should"
>> come only gradually. I also think improvements are better severed in
>> small nibbles than a one big main course.
>>
>> In my past startup, last year, I helped them introduce a non-strict code
>> reviewing process and what it did was not to scare anyone but slowly and
>> gradually everyone started using code reviews and that became a process
>> now. What I learnt was that people like slow changes (don’t put the frog
>> in hot water), processes should be effortless and invisible (you don’t
>> have to think much on how to do it, like say driving a car or touch
>> typing on keyboard), and a cultural change is best implemented without
>> enforcement. For example, in a many countries people don’t honk i.e. the
>> culture even if no one gets a ticket for honking which is my point we
>> need an understanding, a guideline, a protocol to implement a culture not
>> an “enforcement” or team of police.
>>
>>> release, we will come together to discuss flaw in our flow again:) Sorry
>>> if I am too pessimistic on this.
>>
>> To introduce an enforcement would mean take away a committer’s privilege
>> to commit. If you have some ideas start a thread.
>>
>> IMO “pessimistic approach" is not a good approach — you don't ban or
>> restrict people driving cars just because of accidents or ban the
>> Internet just because there are things you don’t like on it, or put
>> people in jail just because they can commit a crime in future. I would
>> want an open and transparent workflow/protocol/guideline that is
>> agreeable to all/most of us and that does not impose any restrictions.
>>
>> Cheers.
>>
>>>
>>> Thanks
>>> -min
>>>
>>> On 8/19/14 10:00 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 19-Aug-2014, at 6:48 pm, Min Chen <mi...@citrix.com> wrote:
>>>>
>>>>> In that case, we should call out this procedure
>>>>>
>>>>> If (you¹re a committer) {
>>>>> Go create a hotfix branch and ask RM to pick it up
>>>>> } else {
>>>>> Go upload your patch and get RM to review your request from
>>>>> reviewboard
>>>>> }
>>>>>
>>>>>
>>>>> in your proposal. I don't want people to have a misunderstanding that
>>>>> with
>>>>> this proposal, RM is not needed anymore. Actually, RM is MORE
>>>>> IMPORTANT
>>>>> with this proposal.
>>>>
>>>> Yes.
>>>>
>>>>> Also, we should also call out the enforcement plan for this procedure.
>>>>
>>>> Subjective. All committers have privilege to commit so enforcement will
>>>> be unnecessary, instead if you find an issue with anyone/anything you
>>>> raise it privately or on public dev ML just like we do it now.
>>>>
>>>>> What happens if somebody still directly commits to release branch
>>>>> after
>>>>> it
>>>>> is cut? Ideally, based on this proposal, after RC is cut, we should
>>>>> only
>>>>> see branch merge/cherry-pick done by RM. If not, RM should revert it
>>>>> to
>>>>> enforce the flow.
>>>>
>>>> At RM’s discretion.
>>>>
>>>> Cheers.
>>>>
>>>>>
>>>>> Thanks
>>>>> -min
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 8/19/14 9:19 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>>>>
>>>>>> Hey,
>>>>>>
>>>>>> On 19-Aug-2014, at 5:34 pm, Pierre-Luc Dion <pd...@cloudops.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks Min for the comment, make sense.
>>>>>>>
>>>>>>> Rohit,  how do we plan to managed merge request or submit one?  I
>>>>>>> don't
>>>>>>> think using the mailing list to keep track of merge request is good,
>>>>>>> does
>>>>>>> https://reviews.apache.org/account/login/ is keep up to date and all
>>>>>>> merge
>>>>>>> request should go there ?
>>>>>>
>>>>>> If (you¹re a committer) {
>>>>>> Go create a hotfix branch and ask RM to pick it up
>>>>>> } else {
>>>>>> Go upload your patch and get RM to review your request from
>>>>>> reviewboard
>>>>>> }
>>>>>>
>>>>>>> What about using Jira to follow merge request ? maybe by having a
>>>>>>> 'merge-request' issue type as sub-task?
>>>>>>
>>>>>> You may do that as long as RMs are okay with that. We don¹t want
>>>>>> people
>>>>>> to attack RMs from too many of channels such as reviewboard, jira,
>>>>>> twitter, fb, linkedin and whatnot; sticking to just using email is
>>>>>> recommended.
>>>>>>
>>>>>>> Also I'm a bit confuse for some commit cases:
>>>>>>>
>>>>>>> Let say that I want to fix the release version display in the API
>>>>>>> doc,
>>>>>>> it
>>>>>>> is not code related right not it show as 4.2.0, it's not a bugfix
>>>>>>> or a
>>>>>>> new
>>>>>>> feature, so should I create branch + merge request  or this type of
>>>>>>> commit
>>>>>>> could be push directly in the release branch (ie: 4.4) ?
>>>>>>
>>>>>> Such cases will ³depend" on your chemistry with the RM, if they¹re
>>>>>> cool
>>>>>> you go ahead alongwith them and fix doc/build fixes directly on
>>>>>> release
>>>>>> (4.4 in the example) branch.
>>>>>>
>>>>>> This is a reason as to why this proposal is flexible, and it does not
>>>>>> introduce any policing but gives a guideline for people to follow.
>>>>>>
>>>>>> Lastly, checking out branches and working on them using git is not
>>>>>> expensive at all, just few keyboard strokes maybe so just don¹t be
>>>>>> afraid.
>>>>>>
>>>>>> Also, for multiple fixes feel free to do several bugfixes and ask the
>>>>>> RM
>>>>>> to pick the fixes from that (hot/bug) fix branch.
>>>>>>
>>>>>> HTH, cheers.
>>>>>>
>>>>>>> Sorry if I add confusion...
>>>>>>>
>>>>>>> Pierre-Luc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 19, 2014 at 11:16 AM, Min Chen <mi...@citrix.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I would rather CI be considered together with this thread, since
>>>>>>>> this
>>>>>>>> thread needs to decide at what condition RM can merge a
>>>>>>>> hotfix/bugfic
>>>>>>>> branch to release branch.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -min
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>>> On Aug 19, 2014, at 8:09 AM, "Pierre-Luc Dion"
>>>>>>>>> <pd...@cloudops.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> +1 ,  CI shouldn't be another topic?
>>>>>>>>>
>>>>>>>>> What is required or missing to have CI in place?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Pierre-Luc DION*
>>>>>>>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>>>>>>>> t 855.652.5683
>>>>>>>>>
>>>>>>>>> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions
>>>>>>>>> Experts
>>>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>>>>>>> w cloudops.com *|* tw @CloudOps_
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav
>>>>>>>>> <ro...@shapeblue.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen
>>>>>>>>>>> <ru...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>> Say you grab a patch from review board and stick it in a hotfix
>>>>>>>>>>> branch,
>>>>>>>>>> test that Šcall for merge on release branch.
>>>>>>>>>>> Do we *merge* to master or can we apply the patch directly to
>>>>>>>>>>> master
>>>>>>>>>> (git am -sŠ) ?
>>>>>>>>>>
>>>>>>>>>> Once the hotfix branch is merged on release branch, we would
>>>>>>>>>> merge
>>>>>>>>>> the
>>>>>>>>>> release branch to master, that will bring the hotfix on master as
>>>>>>>>>> well.
>>>>>>>>>>
>>>>>>>>>> We don¹t want to encourage working on master for fixes that
>>>>>>>>>> qualify
>>>>>>>>>> for
>>>>>>>>>> release branches directly so ideally we should not git am -s the
>>>>>>>>>> patch
>>>>>>>> on
>>>>>>>>>> master. But there is scope for non-strictness for a situation
>>>>>>>>>> needing
>>>>>>>> git
>>>>>>>>>> am -s <patch> on master directly, it would be at the discretion
>>>>>>>>>> of
>>>>>>>>>> the
>>>>>>>> RM
>>>>>>>>>> and committers.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> 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.
>>>>
>>>> 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.
>>>
>>
>> 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.
>

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: [VOTE] Adapting git workflow for release branches

[Min Chen <mi...@citrix.com>]

I personally don't think introducing CI or gerrit or github pull request
will take away a committer's privilege to commit. If you are a stakeholder
who really care about your product, you will not be scared away by this
extra enforcement, this will actually make our cloudstack ecosystem better
and healthier, and will also benefit other contributors in the same
community. To me, this is not a punishment per se, your code is just not
directly committed in, and you can enhance it and commit later. We are not
even requesting for bug-free code, I know, that is not possible in
software world, but at least we should have some stableness in our code to
not block other peers. As far as I know, Linux has much better control
about what patch to be pulled in, which makes it much more stabler than
us. As for your traffic example, at least there we have DMV road test,
traffic light, traffic patrol infrastructure to have basic guard.
CI/gerrit are just like those basic enforcement infrastructure for
CloudStack development process.

I don't want this to become a two-person argument forever. I already
clearly explained my ideas and takes on this. Let's hear others.

Thanks
-min

On 8/19/14 10:55 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:

>tl;dr? hope you read it;
>
>On 19-Aug-2014, at 7:10 pm, Min Chen <mi...@citrix.com> wrote:
>
>> I will hesitate on this "No enforcement" approach in the flow. I bet
>>that
>> without some kind of enforcement, based on past experience, after one
>
>Stakeholder will always care. The system should be optimistic to allow
>things in and not to punish in advance.
>That’s how many scalable opensource project such as Linux, Firefox and
>our own Apache works (people over code that is).
>
>If you’ve any ideas please share. We’ve to find a “non-strict”
>enforcement to get best of all things and I don’t have a solution right
>now to suggest.
>
>“Strict enforcement” won’t be scalable anyway, hackers always find way
>around gaming the system.
>
>Unicorns, Santas and bug-less code perhaps don’t exist IMHO so may never
>guarantee code quality but only improve over time. Even things like
>pacemakers, realtime systems used in mining, surgery, aerospace, mars
>rover etc; openssl (heartbleed) have bugs and issues. This is not to say
>that we should not have code reviews, other processes and automated
>build/CI/smoke-tests are “not” needed, they are needed but they “should"
>come only gradually. I also think improvements are better severed in
>small nibbles than a one big main course.
>
>In my past startup, last year, I helped them introduce a non-strict code
>reviewing process and what it did was not to scare anyone but slowly and
>gradually everyone started using code reviews and that became a process
>now. What I learnt was that people like slow changes (don’t put the frog
>in hot water), processes should be effortless and invisible (you don’t
>have to think much on how to do it, like say driving a car or touch
>typing on keyboard), and a cultural change is best implemented without
>enforcement. For example, in a many countries people don’t honk i.e. the
>culture even if no one gets a ticket for honking which is my point we
>need an understanding, a guideline, a protocol to implement a culture not
>an “enforcement” or team of police.
>
>> release, we will come together to discuss flaw in our flow again:) Sorry
>> if I am too pessimistic on this.
>
>To introduce an enforcement would mean take away a committer’s privilege
>to commit. If you have some ideas start a thread.
>
>IMO “pessimistic approach" is not a good approach — you don't ban or
>restrict people driving cars just because of accidents or ban the
>Internet just because there are things you don’t like on it, or put
>people in jail just because they can commit a crime in future. I would
>want an open and transparent workflow/protocol/guideline that is
>agreeable to all/most of us and that does not impose any restrictions.
>
>Cheers.
>
>>
>> Thanks
>> -min
>>
>> On 8/19/14 10:00 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>
>>> Hi,
>>>
>>> On 19-Aug-2014, at 6:48 pm, Min Chen <mi...@citrix.com> wrote:
>>>
>>>> In that case, we should call out this procedure
>>>>
>>>> If (you¹re a committer) {
>>>> Go create a hotfix branch and ask RM to pick it up
>>>> } else {
>>>> Go upload your patch and get RM to review your request from
>>>>reviewboard
>>>> }
>>>>
>>>>
>>>> in your proposal. I don't want people to have a misunderstanding that
>>>> with
>>>> this proposal, RM is not needed anymore. Actually, RM is MORE
>>>>IMPORTANT
>>>> with this proposal.
>>>
>>> Yes.
>>>
>>>> Also, we should also call out the enforcement plan for this procedure.
>>>
>>> Subjective. All committers have privilege to commit so enforcement will
>>> be unnecessary, instead if you find an issue with anyone/anything you
>>> raise it privately or on public dev ML just like we do it now.
>>>
>>>> What happens if somebody still directly commits to release branch
>>>>after
>>>> it
>>>> is cut? Ideally, based on this proposal, after RC is cut, we should
>>>>only
>>>> see branch merge/cherry-pick done by RM. If not, RM should revert it
>>>>to
>>>> enforce the flow.
>>>
>>> At RM’s discretion.
>>>
>>> Cheers.
>>>
>>>>
>>>> Thanks
>>>> -min
>>>>
>>>>
>>>>
>>>>
>>>> On 8/19/14 9:19 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> On 19-Aug-2014, at 5:34 pm, Pierre-Luc Dion <pd...@cloudops.com>
>>>>>wrote:
>>>>>
>>>>>> Thanks Min for the comment, make sense.
>>>>>>
>>>>>> Rohit,  how do we plan to managed merge request or submit one?  I
>>>>>> don't
>>>>>> think using the mailing list to keep track of merge request is good,
>>>>>> does
>>>>>> https://reviews.apache.org/account/login/ is keep up to date and all
>>>>>> merge
>>>>>> request should go there ?
>>>>>
>>>>> If (you¹re a committer) {
>>>>> Go create a hotfix branch and ask RM to pick it up
>>>>> } else {
>>>>> Go upload your patch and get RM to review your request from
>>>>>reviewboard
>>>>> }
>>>>>
>>>>>> What about using Jira to follow merge request ? maybe by having a
>>>>>> 'merge-request' issue type as sub-task?
>>>>>
>>>>> You may do that as long as RMs are okay with that. We don¹t want
>>>>>people
>>>>> to attack RMs from too many of channels such as reviewboard, jira,
>>>>> twitter, fb, linkedin and whatnot; sticking to just using email is
>>>>> recommended.
>>>>>
>>>>>> Also I'm a bit confuse for some commit cases:
>>>>>>
>>>>>> Let say that I want to fix the release version display in the API
>>>>>>doc,
>>>>>> it
>>>>>> is not code related right not it show as 4.2.0, it's not a bugfix
>>>>>>or a
>>>>>> new
>>>>>> feature, so should I create branch + merge request  or this type of
>>>>>> commit
>>>>>> could be push directly in the release branch (ie: 4.4) ?
>>>>>
>>>>> Such cases will ³depend" on your chemistry with the RM, if they¹re
>>>>>cool
>>>>> you go ahead alongwith them and fix doc/build fixes directly on
>>>>>release
>>>>> (4.4 in the example) branch.
>>>>>
>>>>> This is a reason as to why this proposal is flexible, and it does not
>>>>> introduce any policing but gives a guideline for people to follow.
>>>>>
>>>>> Lastly, checking out branches and working on them using git is not
>>>>> expensive at all, just few keyboard strokes maybe so just don¹t be
>>>>> afraid.
>>>>>
>>>>> Also, for multiple fixes feel free to do several bugfixes and ask the
>>>>> RM
>>>>> to pick the fixes from that (hot/bug) fix branch.
>>>>>
>>>>> HTH, cheers.
>>>>>
>>>>>> Sorry if I add confusion...
>>>>>>
>>>>>> Pierre-Luc
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 19, 2014 at 11:16 AM, Min Chen <mi...@citrix.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I would rather CI be considered together with this thread, since
>>>>>>>this
>>>>>>> thread needs to decide at what condition RM can merge a
>>>>>>>hotfix/bugfic
>>>>>>> branch to release branch.
>>>>>>>
>>>>>>> Thanks
>>>>>>> -min
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>> On Aug 19, 2014, at 8:09 AM, "Pierre-Luc Dion"
>>>>>>>><pd...@cloudops.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> +1 ,  CI shouldn't be another topic?
>>>>>>>>
>>>>>>>> What is required or missing to have CI in place?
>>>>>>>>
>>>>>>>>
>>>>>>>> *Pierre-Luc DION*
>>>>>>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>>>>>>> t 855.652.5683
>>>>>>>>
>>>>>>>> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions
>>>>>>>>Experts
>>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>>>>>> w cloudops.com *|* tw @CloudOps_
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav
>>>>>>>> <ro...@shapeblue.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen
>>>>>>>>>><ru...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>> Say you grab a patch from review board and stick it in a hotfix
>>>>>>>>>> branch,
>>>>>>>>> test that Šcall for merge on release branch.
>>>>>>>>>> Do we *merge* to master or can we apply the patch directly to
>>>>>>>>>> master
>>>>>>>>> (git am -sŠ) ?
>>>>>>>>>
>>>>>>>>> Once the hotfix branch is merged on release branch, we would
>>>>>>>>>merge
>>>>>>>>> the
>>>>>>>>> release branch to master, that will bring the hotfix on master as
>>>>>>>>> well.
>>>>>>>>>
>>>>>>>>> We don¹t want to encourage working on master for fixes that
>>>>>>>>>qualify
>>>>>>>>> for
>>>>>>>>> release branches directly so ideally we should not git am -s the
>>>>>>>>> patch
>>>>>>> on
>>>>>>>>> master. But there is scope for non-strictness for a situation
>>>>>>>>> needing
>>>>>>> git
>>>>>>>>> am -s <patch> on master directly, it would be at the discretion
>>>>>>>>>of
>>>>>>>>> the
>>>>>>> RM
>>>>>>>>> and committers.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>
>>>>>
>>>>> 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.
>>>
>>> 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.
>>
>
>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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

tl;dr? hope you read it;

On 19-Aug-2014, at 7:10 pm, Min Chen <mi...@citrix.com> wrote:

> I will hesitate on this "No enforcement" approach in the flow. I bet that
> without some kind of enforcement, based on past experience, after one

Stakeholder will always care. The system should be optimistic to allow things in and not to punish in advance.
That’s how many scalable opensource project such as Linux, Firefox and our own Apache works (people over code that is).

If you’ve any ideas please share. We’ve to find a “non-strict” enforcement to get best of all things and I don’t have a solution right now to suggest.

“Strict enforcement” won’t be scalable anyway, hackers always find way around gaming the system.

Unicorns, Santas and bug-less code perhaps don’t exist IMHO so may never guarantee code quality but only improve over time. Even things like pacemakers, realtime systems used in mining, surgery, aerospace, mars rover etc; openssl (heartbleed) have bugs and issues. This is not to say that we should not have code reviews, other processes and automated build/CI/smoke-tests are “not” needed, they are needed but they “should" come only gradually. I also think improvements are better severed in small nibbles than a one big main course.

In my past startup, last year, I helped them introduce a non-strict code reviewing process and what it did was not to scare anyone but slowly and gradually everyone started using code reviews and that became a process now. What I learnt was that people like slow changes (don’t put the frog in hot water), processes should be effortless and invisible (you don’t have to think much on how to do it, like say driving a car or touch typing on keyboard), and a cultural change is best implemented without enforcement. For example, in a many countries people don’t honk i.e. the culture even if no one gets a ticket for honking which is my point we need an understanding, a guideline, a protocol to implement a culture not an “enforcement” or team of police.

> release, we will come together to discuss flaw in our flow again:) Sorry
> if I am too pessimistic on this.

To introduce an enforcement would mean take away a committer’s privilege to commit. If you have some ideas start a thread.

IMO “pessimistic approach" is not a good approach — you don't ban or restrict people driving cars just because of accidents or ban the Internet just because there are things you don’t like on it, or put people in jail just because they can commit a crime in future. I would want an open and transparent workflow/protocol/guideline that is agreeable to all/most of us and that does not impose any restrictions.

Cheers.

>
> Thanks
> -min
>
> On 8/19/14 10:00 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>
>> Hi,
>>
>> On 19-Aug-2014, at 6:48 pm, Min Chen <mi...@citrix.com> wrote:
>>
>>> In that case, we should call out this procedure
>>>
>>> If (you¹re a committer) {
>>> Go create a hotfix branch and ask RM to pick it up
>>> } else {
>>> Go upload your patch and get RM to review your request from reviewboard
>>> }
>>>
>>>
>>> in your proposal. I don't want people to have a misunderstanding that
>>> with
>>> this proposal, RM is not needed anymore. Actually, RM is MORE IMPORTANT
>>> with this proposal.
>>
>> Yes.
>>
>>> Also, we should also call out the enforcement plan for this procedure.
>>
>> Subjective. All committers have privilege to commit so enforcement will
>> be unnecessary, instead if you find an issue with anyone/anything you
>> raise it privately or on public dev ML just like we do it now.
>>
>>> What happens if somebody still directly commits to release branch after
>>> it
>>> is cut? Ideally, based on this proposal, after RC is cut, we should only
>>> see branch merge/cherry-pick done by RM. If not, RM should revert it to
>>> enforce the flow.
>>
>> At RM’s discretion.
>>
>> Cheers.
>>
>>>
>>> Thanks
>>> -min
>>>
>>>
>>>
>>>
>>> On 8/19/14 9:19 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>>
>>>> Hey,
>>>>
>>>> On 19-Aug-2014, at 5:34 pm, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>>>
>>>>> Thanks Min for the comment, make sense.
>>>>>
>>>>> Rohit,  how do we plan to managed merge request or submit one?  I
>>>>> don't
>>>>> think using the mailing list to keep track of merge request is good,
>>>>> does
>>>>> https://reviews.apache.org/account/login/ is keep up to date and all
>>>>> merge
>>>>> request should go there ?
>>>>
>>>> If (you¹re a committer) {
>>>> Go create a hotfix branch and ask RM to pick it up
>>>> } else {
>>>> Go upload your patch and get RM to review your request from reviewboard
>>>> }
>>>>
>>>>> What about using Jira to follow merge request ? maybe by having a
>>>>> 'merge-request' issue type as sub-task?
>>>>
>>>> You may do that as long as RMs are okay with that. We don¹t want people
>>>> to attack RMs from too many of channels such as reviewboard, jira,
>>>> twitter, fb, linkedin and whatnot; sticking to just using email is
>>>> recommended.
>>>>
>>>>> Also I'm a bit confuse for some commit cases:
>>>>>
>>>>> Let say that I want to fix the release version display in the API doc,
>>>>> it
>>>>> is not code related right not it show as 4.2.0, it's not a bugfix or a
>>>>> new
>>>>> feature, so should I create branch + merge request  or this type of
>>>>> commit
>>>>> could be push directly in the release branch (ie: 4.4) ?
>>>>
>>>> Such cases will ³depend" on your chemistry with the RM, if they¹re cool
>>>> you go ahead alongwith them and fix doc/build fixes directly on release
>>>> (4.4 in the example) branch.
>>>>
>>>> This is a reason as to why this proposal is flexible, and it does not
>>>> introduce any policing but gives a guideline for people to follow.
>>>>
>>>> Lastly, checking out branches and working on them using git is not
>>>> expensive at all, just few keyboard strokes maybe so just don¹t be
>>>> afraid.
>>>>
>>>> Also, for multiple fixes feel free to do several bugfixes and ask the
>>>> RM
>>>> to pick the fixes from that (hot/bug) fix branch.
>>>>
>>>> HTH, cheers.
>>>>
>>>>> Sorry if I add confusion...
>>>>>
>>>>> Pierre-Luc
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 19, 2014 at 11:16 AM, Min Chen <mi...@citrix.com>
>>>>> wrote:
>>>>>
>>>>>> I would rather CI be considered together with this thread, since this
>>>>>> thread needs to decide at what condition RM can merge a hotfix/bugfic
>>>>>> branch to release branch.
>>>>>>
>>>>>> Thanks
>>>>>> -min
>>>>>> Sent from my iPhone
>>>>>>
>>>>>>> On Aug 19, 2014, at 8:09 AM, "Pierre-Luc Dion" <pd...@cloudops.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> +1 ,  CI shouldn't be another topic?
>>>>>>>
>>>>>>> What is required or missing to have CI in place?
>>>>>>>
>>>>>>>
>>>>>>> *Pierre-Luc DION*
>>>>>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>>>>>> t 855.652.5683
>>>>>>>
>>>>>>> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>>>>> w cloudops.com *|* tw @CloudOps_
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav
>>>>>>> <ro...@shapeblue.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen <ru...@gmail.com>
>>>>>> wrote:
>>>>>>>>> Say you grab a patch from review board and stick it in a hotfix
>>>>>>>>> branch,
>>>>>>>> test that Šcall for merge on release branch.
>>>>>>>>> Do we *merge* to master or can we apply the patch directly to
>>>>>>>>> master
>>>>>>>> (git am -sŠ) ?
>>>>>>>>
>>>>>>>> Once the hotfix branch is merged on release branch, we would merge
>>>>>>>> the
>>>>>>>> release branch to master, that will bring the hotfix on master as
>>>>>>>> well.
>>>>>>>>
>>>>>>>> We don¹t want to encourage working on master for fixes that qualify
>>>>>>>> for
>>>>>>>> release branches directly so ideally we should not git am -s the
>>>>>>>> patch
>>>>>> on
>>>>>>>> master. But there is scope for non-strictness for a situation
>>>>>>>> needing
>>>>>> git
>>>>>>>> am -s <patch> on master directly, it would be at the discretion of
>>>>>>>> the
>>>>>> RM
>>>>>>>> and committers.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>
>>>>
>>>> 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.
>>
>> 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.
>

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: [VOTE] Adapting git workflow for release branches

[Min Chen <mi...@citrix.com>]

I will hesitate on this "No enforcement" approach in the flow. I bet that
without some kind of enforcement, based on past experience, after one
release, we will come together to discuss flaw in our flow again:) Sorry
if I am too pessimistic on this.

Thanks
-min

On 8/19/14 10:00 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:

>Hi,
>
>On 19-Aug-2014, at 6:48 pm, Min Chen <mi...@citrix.com> wrote:
>
>> In that case, we should call out this procedure
>>
>> If (you¹re a committer) {
>> Go create a hotfix branch and ask RM to pick it up
>> } else {
>> Go upload your patch and get RM to review your request from reviewboard
>> }
>>
>>
>> in your proposal. I don't want people to have a misunderstanding that
>>with
>> this proposal, RM is not needed anymore. Actually, RM is MORE IMPORTANT
>> with this proposal.
>
>Yes.
>
>> Also, we should also call out the enforcement plan for this procedure.
>
>Subjective. All committers have privilege to commit so enforcement will
>be unnecessary, instead if you find an issue with anyone/anything you
>raise it privately or on public dev ML just like we do it now.
>
>> What happens if somebody still directly commits to release branch after
>>it
>> is cut? Ideally, based on this proposal, after RC is cut, we should only
>> see branch merge/cherry-pick done by RM. If not, RM should revert it to
>> enforce the flow.
>
>At RM’s discretion.
>
>Cheers.
>
>>
>> Thanks
>> -min
>>
>>
>>
>>
>> On 8/19/14 9:19 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>
>>> Hey,
>>>
>>> On 19-Aug-2014, at 5:34 pm, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>>
>>>> Thanks Min for the comment, make sense.
>>>>
>>>> Rohit,  how do we plan to managed merge request or submit one?  I
>>>>don't
>>>> think using the mailing list to keep track of merge request is good,
>>>> does
>>>> https://reviews.apache.org/account/login/ is keep up to date and all
>>>> merge
>>>> request should go there ?
>>>
>>> If (you¹re a committer) {
>>> Go create a hotfix branch and ask RM to pick it up
>>> } else {
>>> Go upload your patch and get RM to review your request from reviewboard
>>> }
>>>
>>>> What about using Jira to follow merge request ? maybe by having a
>>>> 'merge-request' issue type as sub-task?
>>>
>>> You may do that as long as RMs are okay with that. We don¹t want people
>>> to attack RMs from too many of channels such as reviewboard, jira,
>>> twitter, fb, linkedin and whatnot; sticking to just using email is
>>> recommended.
>>>
>>>> Also I'm a bit confuse for some commit cases:
>>>>
>>>> Let say that I want to fix the release version display in the API doc,
>>>> it
>>>> is not code related right not it show as 4.2.0, it's not a bugfix or a
>>>> new
>>>> feature, so should I create branch + merge request  or this type of
>>>> commit
>>>> could be push directly in the release branch (ie: 4.4) ?
>>>
>>> Such cases will ³depend" on your chemistry with the RM, if they¹re cool
>>> you go ahead alongwith them and fix doc/build fixes directly on release
>>> (4.4 in the example) branch.
>>>
>>> This is a reason as to why this proposal is flexible, and it does not
>>> introduce any policing but gives a guideline for people to follow.
>>>
>>> Lastly, checking out branches and working on them using git is not
>>> expensive at all, just few keyboard strokes maybe so just don¹t be
>>>afraid.
>>>
>>> Also, for multiple fixes feel free to do several bugfixes and ask the
>>>RM
>>> to pick the fixes from that (hot/bug) fix branch.
>>>
>>> HTH, cheers.
>>>
>>>> Sorry if I add confusion...
>>>>
>>>> Pierre-Luc
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Aug 19, 2014 at 11:16 AM, Min Chen <mi...@citrix.com>
>>>>wrote:
>>>>
>>>>> I would rather CI be considered together with this thread, since this
>>>>> thread needs to decide at what condition RM can merge a hotfix/bugfic
>>>>> branch to release branch.
>>>>>
>>>>> Thanks
>>>>> -min
>>>>> Sent from my iPhone
>>>>>
>>>>>> On Aug 19, 2014, at 8:09 AM, "Pierre-Luc Dion" <pd...@cloudops.com>
>>>>> wrote:
>>>>>>
>>>>>> +1 ,  CI shouldn't be another topic?
>>>>>>
>>>>>> What is required or missing to have CI in place?
>>>>>>
>>>>>>
>>>>>> *Pierre-Luc DION*
>>>>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>>>>> t 855.652.5683
>>>>>>
>>>>>> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>>>> w cloudops.com *|* tw @CloudOps_
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav
>>>>>> <ro...@shapeblue.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen <ru...@gmail.com>
>>>>> wrote:
>>>>>>>> Say you grab a patch from review board and stick it in a hotfix
>>>>>>>> branch,
>>>>>>> test that Šcall for merge on release branch.
>>>>>>>> Do we *merge* to master or can we apply the patch directly to
>>>>>>>>master
>>>>>>> (git am -sŠ) ?
>>>>>>>
>>>>>>> Once the hotfix branch is merged on release branch, we would merge
>>>>>>> the
>>>>>>> release branch to master, that will bring the hotfix on master as
>>>>>>> well.
>>>>>>>
>>>>>>> We don¹t want to encourage working on master for fixes that qualify
>>>>>>> for
>>>>>>> release branches directly so ideally we should not git am -s the
>>>>>>> patch
>>>>> on
>>>>>>> master. But there is scope for non-strictness for a situation
>>>>>>>needing
>>>>> git
>>>>>>> am -s <patch> on master directly, it would be at the discretion of
>>>>>>> the
>>>>> RM
>>>>>>> and committers.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>
>>>
>>> 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.
>
>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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

Hi,

On 19-Aug-2014, at 6:48 pm, Min Chen <mi...@citrix.com> wrote:

> In that case, we should call out this procedure
>
> If (you¹re a committer) {
> Go create a hotfix branch and ask RM to pick it up
> } else {
> Go upload your patch and get RM to review your request from reviewboard
> }
>
>
> in your proposal. I don't want people to have a misunderstanding that with
> this proposal, RM is not needed anymore. Actually, RM is MORE IMPORTANT
> with this proposal.

Yes.

> Also, we should also call out the enforcement plan for this procedure.

Subjective. All committers have privilege to commit so enforcement will be unnecessary, instead if you find an issue with anyone/anything you raise it privately or on public dev ML just like we do it now.

> What happens if somebody still directly commits to release branch after it
> is cut? Ideally, based on this proposal, after RC is cut, we should only
> see branch merge/cherry-pick done by RM. If not, RM should revert it to
> enforce the flow.

At RM’s discretion.

Cheers.

>
> Thanks
> -min
>
>
>
>
> On 8/19/14 9:19 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>
>> Hey,
>>
>> On 19-Aug-2014, at 5:34 pm, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>
>>> Thanks Min for the comment, make sense.
>>>
>>> Rohit,  how do we plan to managed merge request or submit one?  I don't
>>> think using the mailing list to keep track of merge request is good,
>>> does
>>> https://reviews.apache.org/account/login/ is keep up to date and all
>>> merge
>>> request should go there ?
>>
>> If (you¹re a committer) {
>> Go create a hotfix branch and ask RM to pick it up
>> } else {
>> Go upload your patch and get RM to review your request from reviewboard
>> }
>>
>>> What about using Jira to follow merge request ? maybe by having a
>>> 'merge-request' issue type as sub-task?
>>
>> You may do that as long as RMs are okay with that. We don¹t want people
>> to attack RMs from too many of channels such as reviewboard, jira,
>> twitter, fb, linkedin and whatnot; sticking to just using email is
>> recommended.
>>
>>> Also I'm a bit confuse for some commit cases:
>>>
>>> Let say that I want to fix the release version display in the API doc,
>>> it
>>> is not code related right not it show as 4.2.0, it's not a bugfix or a
>>> new
>>> feature, so should I create branch + merge request  or this type of
>>> commit
>>> could be push directly in the release branch (ie: 4.4) ?
>>
>> Such cases will ³depend" on your chemistry with the RM, if they¹re cool
>> you go ahead alongwith them and fix doc/build fixes directly on release
>> (4.4 in the example) branch.
>>
>> This is a reason as to why this proposal is flexible, and it does not
>> introduce any policing but gives a guideline for people to follow.
>>
>> Lastly, checking out branches and working on them using git is not
>> expensive at all, just few keyboard strokes maybe so just don¹t be afraid.
>>
>> Also, for multiple fixes feel free to do several bugfixes and ask the RM
>> to pick the fixes from that (hot/bug) fix branch.
>>
>> HTH, cheers.
>>
>>> Sorry if I add confusion...
>>>
>>> Pierre-Luc
>>>
>>>
>>>
>>>
>>> On Tue, Aug 19, 2014 at 11:16 AM, Min Chen <mi...@citrix.com> wrote:
>>>
>>>> I would rather CI be considered together with this thread, since this
>>>> thread needs to decide at what condition RM can merge a hotfix/bugfic
>>>> branch to release branch.
>>>>
>>>> Thanks
>>>> -min
>>>> Sent from my iPhone
>>>>
>>>>> On Aug 19, 2014, at 8:09 AM, "Pierre-Luc Dion" <pd...@cloudops.com>
>>>> wrote:
>>>>>
>>>>> +1 ,  CI shouldn't be another topic?
>>>>>
>>>>> What is required or missing to have CI in place?
>>>>>
>>>>>
>>>>> *Pierre-Luc DION*
>>>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>>>> t 855.652.5683
>>>>>
>>>>> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>>> w cloudops.com *|* tw @CloudOps_
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav
>>>>> <ro...@shapeblue.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen <ru...@gmail.com>
>>>> wrote:
>>>>>>> Say you grab a patch from review board and stick it in a hotfix
>>>>>>> branch,
>>>>>> test that Šcall for merge on release branch.
>>>>>>> Do we *merge* to master or can we apply the patch directly to master
>>>>>> (git am -sŠ) ?
>>>>>>
>>>>>> Once the hotfix branch is merged on release branch, we would merge
>>>>>> the
>>>>>> release branch to master, that will bring the hotfix on master as
>>>>>> well.
>>>>>>
>>>>>> We don¹t want to encourage working on master for fixes that qualify
>>>>>> for
>>>>>> release branches directly so ideally we should not git am -s the
>>>>>> patch
>>>> on
>>>>>> master. But there is scope for non-strictness for a situation needing
>>>> git
>>>>>> am -s <patch> on master directly, it would be at the discretion of
>>>>>> the
>>>> RM
>>>>>> and committers.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>
>>
>> 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.

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: [VOTE] Adapting git workflow for release branches

[Min Chen <mi...@citrix.com>]

In that case, we should call out this procedure

If (you¹re a committer) {
Go create a hotfix branch and ask RM to pick it up
} else {
Go upload your patch and get RM to review your request from reviewboard
}


in your proposal. I don't want people to have a misunderstanding that with
this proposal, RM is not needed anymore. Actually, RM is MORE IMPORTANT
with this proposal.

Also, we should also call out the enforcement plan for this procedure.
What happens if somebody still directly commits to release branch after it
is cut? Ideally, based on this proposal, after RC is cut, we should only
see branch merge/cherry-pick done by RM. If not, RM should revert it to
enforce the flow.

Thanks
-min




On 8/19/14 9:19 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:

>Hey,
>
>On 19-Aug-2014, at 5:34 pm, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>
>> Thanks Min for the comment, make sense.
>>
>> Rohit,  how do we plan to managed merge request or submit one?  I don't
>> think using the mailing list to keep track of merge request is good,
>>does
>> https://reviews.apache.org/account/login/ is keep up to date and all
>>merge
>> request should go there ?
>
>If (you¹re a committer) {
>Go create a hotfix branch and ask RM to pick it up
>} else {
>Go upload your patch and get RM to review your request from reviewboard
>}
>
>> What about using Jira to follow merge request ? maybe by having a
>> 'merge-request' issue type as sub-task?
>
>You may do that as long as RMs are okay with that. We don¹t want people
>to attack RMs from too many of channels such as reviewboard, jira,
>twitter, fb, linkedin and whatnot; sticking to just using email is
>recommended.
>
>> Also I'm a bit confuse for some commit cases:
>>
>> Let say that I want to fix the release version display in the API doc,
>>it
>> is not code related right not it show as 4.2.0, it's not a bugfix or a
>>new
>> feature, so should I create branch + merge request  or this type of
>>commit
>> could be push directly in the release branch (ie: 4.4) ?
>
>Such cases will ³depend" on your chemistry with the RM, if they¹re cool
>you go ahead alongwith them and fix doc/build fixes directly on release
>(4.4 in the example) branch.
>
>This is a reason as to why this proposal is flexible, and it does not
>introduce any policing but gives a guideline for people to follow.
>
>Lastly, checking out branches and working on them using git is not
>expensive at all, just few keyboard strokes maybe so just don¹t be afraid.
>
>Also, for multiple fixes feel free to do several bugfixes and ask the RM
>to pick the fixes from that (hot/bug) fix branch.
>
>HTH, cheers.
>
>> Sorry if I add confusion...
>>
>> Pierre-Luc
>>
>>
>>
>>
>> On Tue, Aug 19, 2014 at 11:16 AM, Min Chen <mi...@citrix.com> wrote:
>>
>>> I would rather CI be considered together with this thread, since this
>>> thread needs to decide at what condition RM can merge a hotfix/bugfic
>>> branch to release branch.
>>>
>>> Thanks
>>> -min
>>> Sent from my iPhone
>>>
>>>> On Aug 19, 2014, at 8:09 AM, "Pierre-Luc Dion" <pd...@cloudops.com>
>>> wrote:
>>>>
>>>> +1 ,  CI shouldn't be another topic?
>>>>
>>>> What is required or missing to have CI in place?
>>>>
>>>>
>>>> *Pierre-Luc DION*
>>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>>> t 855.652.5683
>>>>
>>>> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>> w cloudops.com *|* tw @CloudOps_
>>>>
>>>>
>>>>
>>>> On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav
>>>><ro...@shapeblue.com>
>>>> wrote:
>>>>
>>>>>
>>>>>> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen <ru...@gmail.com>
>>> wrote:
>>>>>> Say you grab a patch from review board and stick it in a hotfix
>>>>>>branch,
>>>>> test that Šcall for merge on release branch.
>>>>>> Do we *merge* to master or can we apply the patch directly to master
>>>>> (git am -sŠ) ?
>>>>>
>>>>> Once the hotfix branch is merged on release branch, we would merge
>>>>>the
>>>>> release branch to master, that will bring the hotfix on master as
>>>>>well.
>>>>>
>>>>> We don¹t want to encourage working on master for fixes that qualify
>>>>>for
>>>>> release branches directly so ideally we should not git am -s the
>>>>>patch
>>> on
>>>>> master. But there is scope for non-strictness for a situation needing
>>> git
>>>>> am -s <patch> on master directly, it would be at the discretion of
>>>>>the
>>> RM
>>>>> and committers.
>>>>>
>>>>> 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.
>>>>>
>>>
>
>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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

Hey,

On 19-Aug-2014, at 5:34 pm, Pierre-Luc Dion <pd...@cloudops.com> wrote:

> Thanks Min for the comment, make sense.
>
> Rohit,  how do we plan to managed merge request or submit one?  I don't
> think using the mailing list to keep track of merge request is good, does
> https://reviews.apache.org/account/login/ is keep up to date and all merge
> request should go there ?

If (you’re a committer) {
Go create a hotfix branch and ask RM to pick it up
} else {
Go upload your patch and get RM to review your request from reviewboard
}

> What about using Jira to follow merge request ? maybe by having a
> 'merge-request' issue type as sub-task?

You may do that as long as RMs are okay with that. We don’t want people to attack RMs from too many of channels such as reviewboard, jira, twitter, fb, linkedin and whatnot; sticking to just using email is recommended.

> Also I'm a bit confuse for some commit cases:
>
> Let say that I want to fix the release version display in the API doc, it
> is not code related right not it show as 4.2.0, it's not a bugfix or a new
> feature, so should I create branch + merge request  or this type of commit
> could be push directly in the release branch (ie: 4.4) ?

Such cases will “depend" on your chemistry with the RM, if they’re cool you go ahead alongwith them and fix doc/build fixes directly on release (4.4 in the example) branch.

This is a reason as to why this proposal is flexible, and it does not introduce any policing but gives a guideline for people to follow.

Lastly, checking out branches and working on them using git is not expensive at all, just few keyboard strokes maybe so just don’t be afraid.

Also, for multiple fixes feel free to do several bugfixes and ask the RM to pick the fixes from that (hot/bug) fix branch.

HTH, cheers.

> Sorry if I add confusion...
>
> Pierre-Luc
>
>
>
>
> On Tue, Aug 19, 2014 at 11:16 AM, Min Chen <mi...@citrix.com> wrote:
>
>> I would rather CI be considered together with this thread, since this
>> thread needs to decide at what condition RM can merge a hotfix/bugfic
>> branch to release branch.
>>
>> Thanks
>> -min
>> Sent from my iPhone
>>
>>> On Aug 19, 2014, at 8:09 AM, "Pierre-Luc Dion" <pd...@cloudops.com>
>> wrote:
>>>
>>> +1 ,  CI shouldn't be another topic?
>>>
>>> What is required or missing to have CI in place?
>>>
>>>
>>> *Pierre-Luc DION*
>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>> t 855.652.5683
>>>
>>> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>> w cloudops.com *|* tw @CloudOps_
>>>
>>>
>>>
>>> On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav <ro...@shapeblue.com>
>>> wrote:
>>>
>>>>
>>>>> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>>>>> Say you grab a patch from review board and stick it in a hotfix branch,
>>>> test that …call for merge on release branch.
>>>>> Do we *merge* to master or can we apply the patch directly to master
>>>> (git am -s…) ?
>>>>
>>>> Once the hotfix branch is merged on release branch, we would merge the
>>>> release branch to master, that will bring the hotfix on master as well.
>>>>
>>>> We don’t want to encourage working on master for fixes that qualify for
>>>> release branches directly so ideally we should not git am -s the patch
>> on
>>>> master. But there is scope for non-strictness for a situation needing
>> git
>>>> am -s <patch> on master directly, it would be at the discretion of the
>> RM
>>>> and committers.
>>>>
>>>> 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.
>>>>
>>

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: [VOTE] Adapting git workflow for release branches

[Pierre-Luc Dion <pd...@cloudops.com>]

Thanks Min for the comment, make sense.

Rohit,  how do we plan to managed merge request or submit one?  I don't
think using the mailing list to keep track of merge request is good, does
https://reviews.apache.org/account/login/ is keep up to date and all merge
request should go there ?
What about using Jira to follow merge request ? maybe by having a
'merge-request' issue type as sub-task?


Also I'm a bit confuse for some commit cases:

Let say that I want to fix the release version display in the API doc, it
is not code related right not it show as 4.2.0, it's not a bugfix or a new
feature, so should I create branch + merge request  or this type of commit
could be push directly in the release branch (ie: 4.4) ?

Sorry if I add confusion...

Pierre-Luc




On Tue, Aug 19, 2014 at 11:16 AM, Min Chen <mi...@citrix.com> wrote:

> I would rather CI be considered together with this thread, since this
> thread needs to decide at what condition RM can merge a hotfix/bugfic
> branch to release branch.
>
> Thanks
> -min
> Sent from my iPhone
>
> > On Aug 19, 2014, at 8:09 AM, "Pierre-Luc Dion" <pd...@cloudops.com>
> wrote:
> >
> > +1 ,  CI shouldn't be another topic?
> >
> > What is required or missing to have CI in place?
> >
> >
> > *Pierre-Luc DION*
> > Architecte de Solution Cloud | Cloud Solutions Architect
> > t 855.652.5683
> >
> > *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> >
> >
> > On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav <ro...@shapeblue.com>
> > wrote:
> >
> >>
> >>> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> >>> Say you grab a patch from review board and stick it in a hotfix branch,
> >> test that …call for merge on release branch.
> >>> Do we *merge* to master or can we apply the patch directly to master
> >> (git am -s…) ?
> >>
> >> Once the hotfix branch is merged on release branch, we would merge the
> >> release branch to master, that will bring the hotfix on master as well.
> >>
> >> We don’t want to encourage working on master for fixes that qualify for
> >> release branches directly so ideally we should not git am -s the patch
> on
> >> master. But there is scope for non-strictness for a situation needing
> git
> >> am -s <patch> on master directly, it would be at the discretion of the
> RM
> >> and committers.
> >>
> >> 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: [VOTE] Adapting git workflow for release branches

[Min Chen <mi...@citrix.com>]

I would rather CI be considered together with this thread, since this thread needs to decide at what condition RM can merge a hotfix/bugfic branch to release branch.

Thanks
-min
Sent from my iPhone

> On Aug 19, 2014, at 8:09 AM, "Pierre-Luc Dion" <pd...@cloudops.com> wrote:
> 
> +1 ,  CI shouldn't be another topic?
> 
> What is required or missing to have CI in place?
> 
> 
> *Pierre-Luc DION*
> Architecte de Solution Cloud | Cloud Solutions Architect
> t 855.652.5683
> 
> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> 
> 
> On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
> 
>> 
>>> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen <ru...@gmail.com> wrote:
>>> Say you grab a patch from review board and stick it in a hotfix branch,
>> test that …call for merge on release branch.
>>> Do we *merge* to master or can we apply the patch directly to master
>> (git am -s…) ?
>> 
>> Once the hotfix branch is merged on release branch, we would merge the
>> release branch to master, that will bring the hotfix on master as well.
>> 
>> We don’t want to encourage working on master for fixes that qualify for
>> release branches directly so ideally we should not git am -s the patch on
>> master. But there is scope for non-strictness for a situation needing git
>> am -s <patch> on master directly, it would be at the discretion of the RM
>> and committers.
>> 
>> 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: [VOTE] Adapting git workflow for release branches

[Pierre-Luc Dion <pd...@cloudops.com>]

+1 ,  CI shouldn't be another topic?

What is required or missing to have CI in place?


*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683

*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_



On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav <ro...@shapeblue.com>
wrote:

>
> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen <ru...@gmail.com> wrote:
> > Say you grab a patch from review board and stick it in a hotfix branch,
> test that …call for merge on release branch.
> > Do we *merge* to master or can we apply the patch directly to master
> (git am -s…) ?
>
> Once the hotfix branch is merged on release branch, we would merge the
> release branch to master, that will bring the hotfix on master as well.
>
> We don’t want to encourage working on master for fixes that qualify for
> release branches directly so ideally we should not git am -s the patch on
> master. But there is scope for non-strictness for a situation needing git
> am -s <patch> on master directly, it would be at the discretion of the RM
> and committers.
>
> 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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

On 19-Aug-2014, at 11:29 am, Sebastien Goasguen <ru...@gmail.com> wrote:
> Say you grab a patch from review board and stick it in a hotfix branch, test that …call for merge on release branch.
> Do we *merge* to master or can we apply the patch directly to master (git am -s…) ?

Once the hotfix branch is merged on release branch, we would merge the release branch to master, that will bring the hotfix on master as well.

We don’t want to encourage working on master for fixes that qualify for release branches directly so ideally we should not git am -s the patch on master. But there is scope for non-strictness for a situation needing git am -s <patch> on master directly, it would be at the discretion of the RM and committers.

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: [VOTE] Adapting git workflow for release branches

[Sebastien Goasguen <ru...@gmail.com>]

On Aug 19, 2014, at 5:23 AM, Rohit Yadav <ro...@shapeblue.com> wrote:

> 
> On 19-Aug-2014, at 10:58 am, Sebastien Goasguen <ru...@gmail.com> wrote:
> 
>> +1
>> 
>> just one question (which was not clear from the email), once RM merges into release branch, who merges into master ?
> 
> Merging on master can be done by the RM or any of the committers (can be even more than once a day), the only challenge will be that they may end up fixing some (smaller conflicts if we do it couple of times a day) conflicts on master.
> 
> It would makes sense that its either the RM or the contributor who fixed the issue for the release branch as they are the stakeholders who would understand it better and may want to get their stuff on master. For example if contributor A sends out a hotfix for release Z, then after their hotfix is merged onto Z, contributor A themselves can merge Z branch to master.

ok makes sense to me.

One more detail -mostly for reference in the thread-:

Say you grab a patch from review board and stick it in a hotfix branch, test that …call for merge on release branch.
Do we *merge* to master or can we apply the patch directly to master (git am -s…) ?

> 
> Cheers.
> 
>> 
>> -sebastien
>> 
>> On Aug 19, 2014, at 4:18 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
>> 
>>> 
>>> On 19-Aug-2014, at 1:54 am, Min Chen <mi...@citrix.com> wrote:
>>> 
>>>> [Min] I don't quite understand why you are saying that it won't cause
>>>> conflicts when we do 4.2 fast-forward to 4.3 branch. What if the codebase
>>>> in 4.3 has been changed a lot?
>>> 
>>> That was an example, yes conflicts can happen but they will be minimal and will happen around since the tag/SHA.
>>> I also said, in places where it’s not possible one can use cherry-picking or manually fixing the bug.
>>> 
>>> 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.
>> 
> 
> 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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

On 19-Aug-2014, at 10:58 am, Sebastien Goasguen <ru...@gmail.com> wrote:

> +1
>
> just one question (which was not clear from the email), once RM merges into release branch, who merges into master ?

Merging on master can be done by the RM or any of the committers (can be even more than once a day), the only challenge will be that they may end up fixing some (smaller conflicts if we do it couple of times a day) conflicts on master.

It would makes sense that its either the RM or the contributor who fixed the issue for the release branch as they are the stakeholders who would understand it better and may want to get their stuff on master. For example if contributor A sends out a hotfix for release Z, then after their hotfix is merged onto Z, contributor A themselves can merge Z branch to master.

Cheers.

>
> -sebastien
>
> On Aug 19, 2014, at 4:18 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
>
>>
>> On 19-Aug-2014, at 1:54 am, Min Chen <mi...@citrix.com> wrote:
>>
>>> [Min] I don't quite understand why you are saying that it won't cause
>>> conflicts when we do 4.2 fast-forward to 4.3 branch. What if the codebase
>>> in 4.3 has been changed a lot?
>>
>> That was an example, yes conflicts can happen but they will be minimal and will happen around since the tag/SHA.
>> I also said, in places where it’s not possible one can use cherry-picking or manually fixing the bug.
>>
>> 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.
>

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: [VOTE] Adapting git workflow for release branches

[Sebastien Goasguen <ru...@gmail.com>]

+1 

just one question (which was not clear from the email), once RM merges into release branch, who merges into master ?

-sebastien

On Aug 19, 2014, at 4:18 AM, Rohit Yadav <ro...@shapeblue.com> wrote:

> 
> On 19-Aug-2014, at 1:54 am, Min Chen <mi...@citrix.com> wrote:
> 
>> [Min] I don't quite understand why you are saying that it won't cause
>> conflicts when we do 4.2 fast-forward to 4.3 branch. What if the codebase
>> in 4.3 has been changed a lot?
> 
> That was an example, yes conflicts can happen but they will be minimal and will happen around since the tag/SHA.
> I also said, in places where it’s not possible one can use cherry-picking or manually fixing the bug.
> 
> 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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

On 19-Aug-2014, at 1:54 am, Min Chen <mi...@citrix.com> wrote:

> [Min] I don't quite understand why you are saying that it won't cause
> conflicts when we do 4.2 fast-forward to 4.3 branch. What if the codebase
> in 4.3 has been changed a lot?

That was an example, yes conflicts can happen but they will be minimal and will happen around since the tag/SHA.
I also said, in places where it’s not possible one can use cherry-picking or manually fixing the bug.

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: [VOTE] Adapting git workflow for release branches

[Min Chen <mi...@citrix.com>]

See my comments inline.

Thanks
-min

On 8/18/14 3:22 PM, "Rohit Yadav" <ro...@shapeblue.com> wrote:

>Hey,
>
>in-line;
>
>On 18-Aug-2014, at 11:09 pm, Min Chen <mi...@citrix.com> wrote:
>> Rohit,
>> I read your proposal, but maybe I mistook your idea:
>>
>> "- After code freeze is declared and release branch is cut out,
>> contributors work on fixing bugs and other changes (such as
>>documentation,
>> build/packaging fixes etc.) first on the release branch (and not
>>master).
>> This is not to restrict anyone working on master, features and other
>> changes can keep landing on master as well. This is to encourage
>> contributors to give more attention to release branches by at least
>>fixing
>> bugs on release branches first and not our current way where we fix it
>>on
>> master and ask RMs to cherry pick it to release branch”.
>
>So, the next point to the above in the proposal tell you how we should do
>it:
>
>“””
>- Changes to release branches can be done by pushing a bugfix/change
>branch and asking the RM to pick it up if they are tested. Our automated
>systems can perform checks on such branches too (starting with a suffix
>that can automatically trigger such builds/tests) and if everything is
>fine, RMs to land the changes to release branches.
>“””
>
>> What do you mean by this? So after release branch is cut, and
>>contributors
>> need to fix a bug (as we experienced so many times in past releases),
>>what
>> should they do? Based on your sentence above, I understood that they can
>> just directly commit to release branch instead of currently checking
>>into
>> some forward branch and RM then cherry-pick it up to release branch to
>> control quality. What is your new proposed approach then? Please
>>clarify.
>
>Sorry if that confused you, this is what a contributor should do:
>(everything in parenthesis below is just a guideline or recommendation
>but not a rule)
>
>1. They should create a branch check’d out from release branch to fix an
>issue for the release branch and push with a bugfix or hotfix prefix
>(possibly with a JIRA bug ID in the branch name) and then ask RM to pick
>it up. In case the contributor is not a committer they can contribute
>their work to be applied on release branch via reviewboard.
>2. Once their hotfix/bugfix branch is merged (-ff preferably to avoid
>having a merge commit) by the RM or the contributor is asked to rework
>their fix and resubmit
>3. Once contributor’s work lands/merges on release branch, this branch is
>merged by either any committer or the RM to master (perhaps several times
>a day using —fast-forward to avoid merge commits). This way changes land
>to master as well.

[Min] Thanks for clarification on this. In this case, this is required
after release branch is cut. For each bug fix, contributor needs to create
a personal branch and fixes there, then ask RM to manually merge branch,
right? So we still need a RM to do such manual things. If so, what is the
advantage of this new model compared to currently contributors committing
into <release>-forward branch and then ask RM to cherry-pick? I am not
against your #3 above.
>
>For supporting multiple release branches, for example fixing a bug on
>multiple branches such as on 4.2, 4.3, 4.4 branches, the contributor
>starts with 4.2 and follows the above and go on until 4.4 and finally
>their fix lands on master. For the long run, if we use the above if a
>bugfix is accepted and applied on 4.2, we could have merged 4.2
>fast-forward to 4.3 branch, and then 4.3 on 4.4 and 4.4 on master. This
>operation will be valid and won’t cause any conflicts etc because if we
>take an example -- the 4.3 branch contains the whole history of 4.2
>(think them as link lists) so merge -ff will result in landing the
>original bugfix to the next branch. This is the flow of change we could
>benefit from and it’s a guideline and not a rule and one will be still
>free to cherry-pick or fixing something manually per release branch.

[Min] I don't quite understand why you are saying that it won't cause
conflicts when we do 4.2 fast-forward to 4.3 branch. What if the codebase
in 4.3 has been changed a lot?

>
>With our (already) releases we don’t backport or fix bugs, I hope such a
>workflow can be helpful for doing a LTS or long term maintenance release.
>
>The proposal also consists of scope of non-strictness and changeability,
>quoting:
>“””
>- Nothing is written in stones, this should be change-able. And, this can
>only work if we all agree to follow this with 4.5
>“”"
>
>Cheers.
>
>
>>
>> Thanks
>> -min
>>
>> On 8/18/14 12:06 PM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>
>>> Min,
>>>
>>> On 18-Aug-2014, at 8:25 pm, Min Chen <mi...@citrix.com> wrote:
>>>
>>>> Rohit,
>>>>
>>>> I think that Edison and I have clearly indicated our objection reason
>>>>in
>>>> our previous email. Based on current cloudstack quality, RM needs to
>>>> have
>>>> control over what commits to be in release branch to get a release at
>>>> least having some quality. With this proposed model, how can you
>>>> guarantee
>>>> the quality of a release? We cannot just talk about changing a process
>>>> without resolving this important concern. What is your solution to
>>>>this
>>>> concern?
>>>
>>> In my proposal we’re not saying people “can" commit directly to release
>>> branches, I suggest you re-read the proposal. I cannot emphasis this
>>> enough that this does not try to solve the issue you’re raising (which
>>> deserves a thread of its own), so the expectation from everyone is to
>>> stick to the agenda and comment on it.
>>>
>>> Min, I’ve said this at least four times now I feel like people are just
>>> skimming emails :P If they are, may I deserve their attention to read
>>>my
>>> email with full attention like I do when I read theirs?
>>>
>>> We’re not giving power to everyone commit directly on release branches,
>>> so we’re not changing the status quo around this issue so there is no
>>> point of questioning “release quality”.
>>>
>>> This sort of workflow is something used at several companies such as
>>> Google and Facebook which has turned out to work for them.
>>>
>>> If you find any issues or challenges with this I would love to hear
>>>from
>>> you. At the end of the day as an individual wearing your Apache hat
>>>it’s
>>> your call and right to votes and opinions so we respect your votes but
>>>it
>>> would be only encouraging if they are backed by a good reason.
>>>
>>> Lastly, I don’t have the “unicorn" solution that will guarantee quality
>>> of a release and I think perhaps it does not exist.
>>>
>>> This proposal does not aim to solve the “release quality issue” but to:
>>>
>>> - encourage involvement of contributors during release: My personal
>>> opinion is that we’ve a major problem that unless a commercial
>>> distribution’s releases is based on ACS release, many of the
>>>“sponsored”
>>> developers won’t participate much in opensource ACS releasess. How do
>>>we
>>> solve it? I guess we need some way to increase participation, by
>>> increasing participation we’ll have much better release quality than
>>> perhaps that will less involvement.
>>> - a guideline to reduce conflicts and make sure no commit is missed or
>>> misplaced
>>> - give a flow of change (baseline protocol) on how to maintain multiple
>>> release branches
>>>
>>> Min and others, I would welcome if you’ve any issues or challenges you
>>> can find with “what” the above will try to implement.
>>>
>>> Cheers.
>>>
>>>
>>>>
>>>> Thanks
>>>> -min
>>>>
>>>>
>>>> On 8/18/14 10:59 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> @Jessica ‹ Can you please suggest what¹s wrong with the ³things² that
>>>>> were proposed here as I could not figure out your or Min¹s or
>>>>>Edison's
>>>>> individual opinion and reason behind the vote.
>>>>>
>>>>> We have three -1s (1 binding) but none of them share valid reasons or
>>>>> concerns that would point out issues and challenges with adopting the
>>>>> proposed items so we¹ll continue with the voting.
>>>>>
>>>>> Min, Jessica, Edison ‹ I would love to know what¹s wrong in the
>>>>> "proposed
>>>>> things" so we don¹t make mistake.
>>>>>
>>>>> @Rajani ‹ Thanks, but when we should cut a release branch is a
>>>>> different
>>>>> topic and IMO is per the RM¹s discretion so if you¹ve any ideas or
>>>>> proposals please go ahead and start a thread on that.
>>>>>
>>>>> Cheers.
>>>>>
>>>>> On 18-Aug-2014, at 6:52 pm, Jessica Wang <Je...@citrix.com>
>>>>> wrote:
>>>>>
>>>>>> I agree with Edison.
>>>>>> I am -1 on this as well.
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Edison Su [mailto:Edison.su@citrix.com]
>>>>>> Sent: Saturday, August 16, 2014 12:11 PM
>>>>>> To: dev
>>>>>> Subject: RE: [VOTE] Adapting git workflow for release branches
>>>>>>
>>>>>> I agree with what Min said on thread:
>>>>>> http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with
>>>>>> your answer:
>>>>>> Currently we don't have a CI running continuously, no code review,
>>>>>> it's
>>>>>> too risky to let developer check in whatever commit they want into
>>>>>> release branch. RM needs to have to control over what commit should
>>>>>>be
>>>>>> put into release branch and what should not, otherwise, we could get
>>>>>> into a stage where no control on the quality.
>>>>>> How RM will do the control, that's something we could discuss. I
>>>>>>know,
>>>>>> current model is not scale, as RM needs to manually cherry pick
>>>>>> commits
>>>>>> into release branch. The way I thinking about, is all the commits
>>>>>>put
>>>>>> into release branch, must be put into review board, or gerrit, must
>>>>>>be
>>>>>> passed by CI and reviewers, then the commits can be put into release
>>>>>> branch.
>>>>>> For above reason, I am -1(binding) on your proposal for now until we
>>>>>> solve the quality control problem.
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
>>>>>>> Sent: Friday, August 15, 2014 3:25 AM
>>>>>>> To: dev
>>>>>>> Subject: [VOTE] Adapting git workflow for release branches
>>>>>>>
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>> With reference to my proposal on changing our release-master commit
>>>>>>> flow
>>>>>>> [1], I would like to start a voting thread to decide on the
>>>>>>>adoption
>>>>>>> starting 4.5
>>>>>>> release. Any opinion, ideas, modifications is welcome to help
>>>>>>>reach a
>>>>>>> consensus and improve our present situation.
>>>>>>>
>>>>>>> Today's Friday so it will be only fair to extend the voting window
>>>>>>>to
>>>>>>> more
>>>>>>> than our usual 72 hours window.
>>>>>>> Therefore, we'll end this voting on Wednesday, 20 August 2014 at
>>>>>>> 18:00H
>>>>>>> UTC giving about 5 days of time for people to share what works and
>>>>>>> what
>>>>>>> does not. We'll stop anytime we've three -1s (binding).
>>>>>>>
>>>>>>> Short summary:
>>>>>>>
>>>>>>> - Base line protocol: Continuous changes from release/stable
>>>>>>>branches
>>>>>>> to
>>>>>>> master/unable branches
>>>>>>> - Get contributors more engaged with release branches by working
>>>>>>> (fixing
>>>>>>> bugs, docs etc.) on release branches first (and not on master)
>>>>>>> - Fixes on release branches are recommended (non strict
>>>>>>>enforcement)
>>>>>>> go
>>>>>>> via a hotfix/bugfix branch that get automatically tested by
>>>>>>>Jenkins,
>>>>>>> when
>>>>>>> they are green RMs get the changes to release branch
>>>>>>>
>>>>>>> Long Summary of what we'll adopt: (I'm skipping writing them on
>>>>>>>wiki,
>>>>>>> as this
>>>>>>> may change/modify in this thread)
>>>>>>>
>>>>>>> - Continuous flow of changes from stable branches to un-stables
>>>>>>>ones
>>>>>>> i.e.
>>>>>>> from release branches to master and from master to features etc.
>>>>>>>Use
>>>>>>> of
>>>>>>> merge -fast-forward is encourages over cherry-picking and -no-ff
>>>>>>>(no
>>>>>>> ff
>>>>>>> will create merge commit). This happens couple of times a day to
>>>>>>> ensure we
>>>>>>> get solid/robust changes from release branches (such as bugfixes
>>>>>>> etc.)
>>>>>>> on
>>>>>>> master, any conflicts will be resolved. If we do it continuously
>>>>>>> we'll
>>>>>>> also save
>>>>>>> ourselves from a big conflict at the end of the release cycle and
>>>>>>> we'll also
>>>>>>> avoid missing/misplacing any commit when cherry-picking.
>>>>>>>
>>>>>>> - After code freeze is declared and release branch is cut out,
>>>>>>> contributors
>>>>>>> work on fixing bugs and other changes (such as documentation,
>>>>>>> build/packaging fixes etc.) first on the release branch (and not
>>>>>>> master). This
>>>>>>> is not to restrict anyone working on master, features and other
>>>>>>> changes can
>>>>>>> keep landing on master as well. This is to encourage contributors
>>>>>>>to
>>>>>>> give
>>>>>>> more attention to release branches by at least fixing bugs on
>>>>>>>release
>>>>>>> branches first and not our current way where we fix it on master
>>>>>>>and
>>>>>>> ask
>>>>>>> RMs to cherry pick it to release branch.
>>>>>>>
>>>>>>> - Changes to release branches can be done by pushing a
>>>>>>>bugfix/change
>>>>>>> branch and asking the RM to pick it up if they are tested. Our
>>>>>>> automated
>>>>>>> systems can perform checks on such branches too (starting with a
>>>>>>> suffix that
>>>>>>> can automatically trigger such builds/tests) and if everything is
>>>>>>> fine, RMs to
>>>>>>> land the changes to release branches.
>>>>>>>
>>>>>>> - Nothing is written in stones, this should be change-able. And,
>>>>>>>this
>>>>>>> can only
>>>>>>> work if we all agree to follow this with 4.5
>>>>>>>
>>>>>>> To make the best of this thread, please keep your reply short,
>>>>>>> constructive
>>>>>>> and to the point..
>>>>>>> Please share your opinion on this proposal with suitable reasons:
>>>>>>>
>>>>>>> [ ] +1  approve
>>>>>>> [ ] +0  no opinion
>>>>>>> [ ] -1  disapprove (and reason why)
>>>>>>>
>>>>>>> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>> 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.
>>>
>>> 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.
>>
>
>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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

Hey,

in-line;

On 18-Aug-2014, at 11:09 pm, Min Chen <mi...@citrix.com> wrote:
> Rohit,
> I read your proposal, but maybe I mistook your idea:
>
> "- After code freeze is declared and release branch is cut out,
> contributors work on fixing bugs and other changes (such as documentation,
> build/packaging fixes etc.) first on the release branch (and not master).
> This is not to restrict anyone working on master, features and other
> changes can keep landing on master as well. This is to encourage
> contributors to give more attention to release branches by at least fixing
> bugs on release branches first and not our current way where we fix it on
> master and ask RMs to cherry pick it to release branch”.

So, the next point to the above in the proposal tell you how we should do it:

“””
- Changes to release branches can be done by pushing a bugfix/change branch and asking the RM to pick it up if they are tested. Our automated systems can perform checks on such branches too (starting with a suffix that can automatically trigger such builds/tests) and if everything is fine, RMs to land the changes to release branches.
“””

> What do you mean by this? So after release branch is cut, and contributors
> need to fix a bug (as we experienced so many times in past releases), what
> should they do? Based on your sentence above, I understood that they can
> just directly commit to release branch instead of currently checking into
> some forward branch and RM then cherry-pick it up to release branch to
> control quality. What is your new proposed approach then? Please clarify.

Sorry if that confused you, this is what a contributor should do: (everything in parenthesis below is just a guideline or recommendation but not a rule)

1. They should create a branch check’d out from release branch to fix an issue for the release branch and push with a bugfix or hotfix prefix (possibly with a JIRA bug ID in the branch name) and then ask RM to pick it up. In case the contributor is not a committer they can contribute their work to be applied on release branch via reviewboard.
2. Once their hotfix/bugfix branch is merged (-ff preferably to avoid having a merge commit) by the RM or the contributor is asked to rework their fix and resubmit
3. Once contributor’s work lands/merges on release branch, this branch is merged by either any committer or the RM to master (perhaps several times a day using —fast-forward to avoid merge commits). This way changes land to master as well.

For supporting multiple release branches, for example fixing a bug on multiple branches such as on 4.2, 4.3, 4.4 branches, the contributor starts with 4.2 and follows the above and go on until 4.4 and finally their fix lands on master. For the long run, if we use the above if a bugfix is accepted and applied on 4.2, we could have merged 4.2 fast-forward to 4.3 branch, and then 4.3 on 4.4 and 4.4 on master. This operation will be valid and won’t cause any conflicts etc because if we take an example -- the 4.3 branch contains the whole history of 4.2 (think them as link lists) so merge -ff will result in landing the original bugfix to the next branch. This is the flow of change we could benefit from and it’s a guideline and not a rule and one will be still free to cherry-pick or fixing something manually per release branch.

With our (already) releases we don’t backport or fix bugs, I hope such a workflow can be helpful for doing a LTS or long term maintenance release.

The proposal also consists of scope of non-strictness and changeability, quoting:
“””
- Nothing is written in stones, this should be change-able. And, this can only work if we all agree to follow this with 4.5
“”"

Cheers.


>
> Thanks
> -min
>
> On 8/18/14 12:06 PM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>
>> Min,
>>
>> On 18-Aug-2014, at 8:25 pm, Min Chen <mi...@citrix.com> wrote:
>>
>>> Rohit,
>>>
>>> I think that Edison and I have clearly indicated our objection reason in
>>> our previous email. Based on current cloudstack quality, RM needs to
>>> have
>>> control over what commits to be in release branch to get a release at
>>> least having some quality. With this proposed model, how can you
>>> guarantee
>>> the quality of a release? We cannot just talk about changing a process
>>> without resolving this important concern. What is your solution to this
>>> concern?
>>
>> In my proposal we’re not saying people “can" commit directly to release
>> branches, I suggest you re-read the proposal. I cannot emphasis this
>> enough that this does not try to solve the issue you’re raising (which
>> deserves a thread of its own), so the expectation from everyone is to
>> stick to the agenda and comment on it.
>>
>> Min, I’ve said this at least four times now I feel like people are just
>> skimming emails :P If they are, may I deserve their attention to read my
>> email with full attention like I do when I read theirs?
>>
>> We’re not giving power to everyone commit directly on release branches,
>> so we’re not changing the status quo around this issue so there is no
>> point of questioning “release quality”.
>>
>> This sort of workflow is something used at several companies such as
>> Google and Facebook which has turned out to work for them.
>>
>> If you find any issues or challenges with this I would love to hear from
>> you. At the end of the day as an individual wearing your Apache hat it’s
>> your call and right to votes and opinions so we respect your votes but it
>> would be only encouraging if they are backed by a good reason.
>>
>> Lastly, I don’t have the “unicorn" solution that will guarantee quality
>> of a release and I think perhaps it does not exist.
>>
>> This proposal does not aim to solve the “release quality issue” but to:
>>
>> - encourage involvement of contributors during release: My personal
>> opinion is that we’ve a major problem that unless a commercial
>> distribution’s releases is based on ACS release, many of the “sponsored”
>> developers won’t participate much in opensource ACS releasess. How do we
>> solve it? I guess we need some way to increase participation, by
>> increasing participation we’ll have much better release quality than
>> perhaps that will less involvement.
>> - a guideline to reduce conflicts and make sure no commit is missed or
>> misplaced
>> - give a flow of change (baseline protocol) on how to maintain multiple
>> release branches
>>
>> Min and others, I would welcome if you’ve any issues or challenges you
>> can find with “what” the above will try to implement.
>>
>> Cheers.
>>
>>
>>>
>>> Thanks
>>> -min
>>>
>>>
>>> On 8/18/14 10:59 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> @Jessica ‹ Can you please suggest what¹s wrong with the ³things² that
>>>> were proposed here as I could not figure out your or Min¹s or Edison's
>>>> individual opinion and reason behind the vote.
>>>>
>>>> We have three -1s (1 binding) but none of them share valid reasons or
>>>> concerns that would point out issues and challenges with adopting the
>>>> proposed items so we¹ll continue with the voting.
>>>>
>>>> Min, Jessica, Edison ‹ I would love to know what¹s wrong in the
>>>> "proposed
>>>> things" so we don¹t make mistake.
>>>>
>>>> @Rajani ‹ Thanks, but when we should cut a release branch is a
>>>> different
>>>> topic and IMO is per the RM¹s discretion so if you¹ve any ideas or
>>>> proposals please go ahead and start a thread on that.
>>>>
>>>> Cheers.
>>>>
>>>> On 18-Aug-2014, at 6:52 pm, Jessica Wang <Je...@citrix.com>
>>>> wrote:
>>>>
>>>>> I agree with Edison.
>>>>> I am -1 on this as well.
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Edison Su [mailto:Edison.su@citrix.com]
>>>>> Sent: Saturday, August 16, 2014 12:11 PM
>>>>> To: dev
>>>>> Subject: RE: [VOTE] Adapting git workflow for release branches
>>>>>
>>>>> I agree with what Min said on thread:
>>>>> http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with
>>>>> your answer:
>>>>> Currently we don't have a CI running continuously, no code review,
>>>>> it's
>>>>> too risky to let developer check in whatever commit they want into
>>>>> release branch. RM needs to have to control over what commit should be
>>>>> put into release branch and what should not, otherwise, we could get
>>>>> into a stage where no control on the quality.
>>>>> How RM will do the control, that's something we could discuss. I know,
>>>>> current model is not scale, as RM needs to manually cherry pick
>>>>> commits
>>>>> into release branch. The way I thinking about, is all the commits put
>>>>> into release branch, must be put into review board, or gerrit, must be
>>>>> passed by CI and reviewers, then the commits can be put into release
>>>>> branch.
>>>>> For above reason, I am -1(binding) on your proposal for now until we
>>>>> solve the quality control problem.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
>>>>>> Sent: Friday, August 15, 2014 3:25 AM
>>>>>> To: dev
>>>>>> Subject: [VOTE] Adapting git workflow for release branches
>>>>>>
>>>>>> Hello everyone,
>>>>>>
>>>>>> With reference to my proposal on changing our release-master commit
>>>>>> flow
>>>>>> [1], I would like to start a voting thread to decide on the adoption
>>>>>> starting 4.5
>>>>>> release. Any opinion, ideas, modifications is welcome to help reach a
>>>>>> consensus and improve our present situation.
>>>>>>
>>>>>> Today's Friday so it will be only fair to extend the voting window to
>>>>>> more
>>>>>> than our usual 72 hours window.
>>>>>> Therefore, we'll end this voting on Wednesday, 20 August 2014 at
>>>>>> 18:00H
>>>>>> UTC giving about 5 days of time for people to share what works and
>>>>>> what
>>>>>> does not. We'll stop anytime we've three -1s (binding).
>>>>>>
>>>>>> Short summary:
>>>>>>
>>>>>> - Base line protocol: Continuous changes from release/stable branches
>>>>>> to
>>>>>> master/unable branches
>>>>>> - Get contributors more engaged with release branches by working
>>>>>> (fixing
>>>>>> bugs, docs etc.) on release branches first (and not on master)
>>>>>> - Fixes on release branches are recommended (non strict enforcement)
>>>>>> go
>>>>>> via a hotfix/bugfix branch that get automatically tested by Jenkins,
>>>>>> when
>>>>>> they are green RMs get the changes to release branch
>>>>>>
>>>>>> Long Summary of what we'll adopt: (I'm skipping writing them on wiki,
>>>>>> as this
>>>>>> may change/modify in this thread)
>>>>>>
>>>>>> - Continuous flow of changes from stable branches to un-stables ones
>>>>>> i.e.
>>>>>> from release branches to master and from master to features etc. Use
>>>>>> of
>>>>>> merge -fast-forward is encourages over cherry-picking and -no-ff (no
>>>>>> ff
>>>>>> will create merge commit). This happens couple of times a day to
>>>>>> ensure we
>>>>>> get solid/robust changes from release branches (such as bugfixes
>>>>>> etc.)
>>>>>> on
>>>>>> master, any conflicts will be resolved. If we do it continuously
>>>>>> we'll
>>>>>> also save
>>>>>> ourselves from a big conflict at the end of the release cycle and
>>>>>> we'll also
>>>>>> avoid missing/misplacing any commit when cherry-picking.
>>>>>>
>>>>>> - After code freeze is declared and release branch is cut out,
>>>>>> contributors
>>>>>> work on fixing bugs and other changes (such as documentation,
>>>>>> build/packaging fixes etc.) first on the release branch (and not
>>>>>> master). This
>>>>>> is not to restrict anyone working on master, features and other
>>>>>> changes can
>>>>>> keep landing on master as well. This is to encourage contributors to
>>>>>> give
>>>>>> more attention to release branches by at least fixing bugs on release
>>>>>> branches first and not our current way where we fix it on master and
>>>>>> ask
>>>>>> RMs to cherry pick it to release branch.
>>>>>>
>>>>>> - Changes to release branches can be done by pushing a bugfix/change
>>>>>> branch and asking the RM to pick it up if they are tested. Our
>>>>>> automated
>>>>>> systems can perform checks on such branches too (starting with a
>>>>>> suffix that
>>>>>> can automatically trigger such builds/tests) and if everything is
>>>>>> fine, RMs to
>>>>>> land the changes to release branches.
>>>>>>
>>>>>> - Nothing is written in stones, this should be change-able. And, this
>>>>>> can only
>>>>>> work if we all agree to follow this with 4.5
>>>>>>
>>>>>> To make the best of this thread, please keep your reply short,
>>>>>> constructive
>>>>>> and to the point..
>>>>>> Please share your opinion on this proposal with suitable reasons:
>>>>>>
>>>>>> [ ] +1  approve
>>>>>> [ ] +0  no opinion
>>>>>> [ ] -1  disapprove (and reason why)
>>>>>>
>>>>>> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
>>>>>>
>>>>>> 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.
>>>>
>>>> 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.
>>
>> 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.
>

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: [VOTE] Adapting git workflow for release branches

[Min Chen <mi...@citrix.com>]

Rohit,
	I read your proposal, but maybe I mistook your idea:

"- After code freeze is declared and release branch is cut out,
contributors work on fixing bugs and other changes (such as documentation,
build/packaging fixes etc.) first on the release branch (and not master).
This is not to restrict anyone working on master, features and other
changes can keep landing on master as well. This is to encourage
contributors to give more attention to release branches by at least fixing
bugs on release branches first and not our current way where we fix it on
master and ask RMs to cherry pick it to release branch".

What do you mean by this? So after release branch is cut, and contributors
need to fix a bug (as we experienced so many times in past releases), what
should they do? Based on your sentence above, I understood that they can
just directly commit to release branch instead of currently checking into
some forward branch and RM then cherry-pick it up to release branch to
control quality. What is your new proposed approach then? Please clarify.

	Thanks
	-min

On 8/18/14 12:06 PM, "Rohit Yadav" <ro...@shapeblue.com> wrote:

>Min,
>
>On 18-Aug-2014, at 8:25 pm, Min Chen <mi...@citrix.com> wrote:
>
>> Rohit,
>>
>> I think that Edison and I have clearly indicated our objection reason in
>> our previous email. Based on current cloudstack quality, RM needs to
>>have
>> control over what commits to be in release branch to get a release at
>> least having some quality. With this proposed model, how can you
>>guarantee
>> the quality of a release? We cannot just talk about changing a process
>> without resolving this important concern. What is your solution to this
>> concern?
>
>In my proposal we’re not saying people “can" commit directly to release
>branches, I suggest you re-read the proposal. I cannot emphasis this
>enough that this does not try to solve the issue you’re raising (which
>deserves a thread of its own), so the expectation from everyone is to
>stick to the agenda and comment on it.
>
>Min, I’ve said this at least four times now I feel like people are just
>skimming emails :P If they are, may I deserve their attention to read my
>email with full attention like I do when I read theirs?
>
>We’re not giving power to everyone commit directly on release branches,
>so we’re not changing the status quo around this issue so there is no
>point of questioning “release quality”.
>
>This sort of workflow is something used at several companies such as
>Google and Facebook which has turned out to work for them.
>
>If you find any issues or challenges with this I would love to hear from
>you. At the end of the day as an individual wearing your Apache hat it’s
>your call and right to votes and opinions so we respect your votes but it
>would be only encouraging if they are backed by a good reason.
>
>Lastly, I don’t have the “unicorn" solution that will guarantee quality
>of a release and I think perhaps it does not exist.
>
>This proposal does not aim to solve the “release quality issue” but to:
>
>- encourage involvement of contributors during release: My personal
>opinion is that we’ve a major problem that unless a commercial
>distribution’s releases is based on ACS release, many of the “sponsored”
>developers won’t participate much in opensource ACS releasess. How do we
>solve it? I guess we need some way to increase participation, by
>increasing participation we’ll have much better release quality than
>perhaps that will less involvement.
>- a guideline to reduce conflicts and make sure no commit is missed or
>misplaced
>- give a flow of change (baseline protocol) on how to maintain multiple
>release branches
>
>Min and others, I would welcome if you’ve any issues or challenges you
>can find with “what” the above will try to implement.
>
>Cheers.
>
>
>>
>> Thanks
>> -min
>>
>>
>> On 8/18/14 10:59 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>
>>> Hi,
>>>
>>> @Jessica ‹ Can you please suggest what¹s wrong with the ³things² that
>>> were proposed here as I could not figure out your or Min¹s or Edison's
>>> individual opinion and reason behind the vote.
>>>
>>> We have three -1s (1 binding) but none of them share valid reasons or
>>> concerns that would point out issues and challenges with adopting the
>>> proposed items so we¹ll continue with the voting.
>>>
>>> Min, Jessica, Edison ‹ I would love to know what¹s wrong in the
>>>"proposed
>>> things" so we don¹t make mistake.
>>>
>>> @Rajani ‹ Thanks, but when we should cut a release branch is a
>>>different
>>> topic and IMO is per the RM¹s discretion so if you¹ve any ideas or
>>> proposals please go ahead and start a thread on that.
>>>
>>> Cheers.
>>>
>>> On 18-Aug-2014, at 6:52 pm, Jessica Wang <Je...@citrix.com>
>>>wrote:
>>>
>>>> I agree with Edison.
>>>> I am -1 on this as well.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Edison Su [mailto:Edison.su@citrix.com]
>>>> Sent: Saturday, August 16, 2014 12:11 PM
>>>> To: dev
>>>> Subject: RE: [VOTE] Adapting git workflow for release branches
>>>>
>>>> I agree with what Min said on thread:
>>>> http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with
>>>> your answer:
>>>> Currently we don't have a CI running continuously, no code review,
>>>>it's
>>>> too risky to let developer check in whatever commit they want into
>>>> release branch. RM needs to have to control over what commit should be
>>>> put into release branch and what should not, otherwise, we could get
>>>> into a stage where no control on the quality.
>>>> How RM will do the control, that's something we could discuss. I know,
>>>> current model is not scale, as RM needs to manually cherry pick
>>>>commits
>>>> into release branch. The way I thinking about, is all the commits put
>>>> into release branch, must be put into review board, or gerrit, must be
>>>> passed by CI and reviewers, then the commits can be put into release
>>>> branch.
>>>> For above reason, I am -1(binding) on your proposal for now until we
>>>> solve the quality control problem.
>>>>
>>>>> -----Original Message-----
>>>>> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
>>>>> Sent: Friday, August 15, 2014 3:25 AM
>>>>> To: dev
>>>>> Subject: [VOTE] Adapting git workflow for release branches
>>>>>
>>>>> Hello everyone,
>>>>>
>>>>> With reference to my proposal on changing our release-master commit
>>>>> flow
>>>>> [1], I would like to start a voting thread to decide on the adoption
>>>>> starting 4.5
>>>>> release. Any opinion, ideas, modifications is welcome to help reach a
>>>>> consensus and improve our present situation.
>>>>>
>>>>> Today's Friday so it will be only fair to extend the voting window to
>>>>> more
>>>>> than our usual 72 hours window.
>>>>> Therefore, we'll end this voting on Wednesday, 20 August 2014 at
>>>>>18:00H
>>>>> UTC giving about 5 days of time for people to share what works and
>>>>>what
>>>>> does not. We'll stop anytime we've three -1s (binding).
>>>>>
>>>>> Short summary:
>>>>>
>>>>> - Base line protocol: Continuous changes from release/stable branches
>>>>> to
>>>>> master/unable branches
>>>>> - Get contributors more engaged with release branches by working
>>>>> (fixing
>>>>> bugs, docs etc.) on release branches first (and not on master)
>>>>> - Fixes on release branches are recommended (non strict enforcement)
>>>>>go
>>>>> via a hotfix/bugfix branch that get automatically tested by Jenkins,
>>>>> when
>>>>> they are green RMs get the changes to release branch
>>>>>
>>>>> Long Summary of what we'll adopt: (I'm skipping writing them on wiki,
>>>>> as this
>>>>> may change/modify in this thread)
>>>>>
>>>>> - Continuous flow of changes from stable branches to un-stables ones
>>>>> i.e.
>>>>> from release branches to master and from master to features etc. Use
>>>>>of
>>>>> merge -fast-forward is encourages over cherry-picking and -no-ff (no
>>>>>ff
>>>>> will create merge commit). This happens couple of times a day to
>>>>> ensure we
>>>>> get solid/robust changes from release branches (such as bugfixes
>>>>>etc.)
>>>>> on
>>>>> master, any conflicts will be resolved. If we do it continuously
>>>>>we'll
>>>>> also save
>>>>> ourselves from a big conflict at the end of the release cycle and
>>>>> we'll also
>>>>> avoid missing/misplacing any commit when cherry-picking.
>>>>>
>>>>> - After code freeze is declared and release branch is cut out,
>>>>> contributors
>>>>> work on fixing bugs and other changes (such as documentation,
>>>>> build/packaging fixes etc.) first on the release branch (and not
>>>>> master). This
>>>>> is not to restrict anyone working on master, features and other
>>>>> changes can
>>>>> keep landing on master as well. This is to encourage contributors to
>>>>> give
>>>>> more attention to release branches by at least fixing bugs on release
>>>>> branches first and not our current way where we fix it on master and
>>>>> ask
>>>>> RMs to cherry pick it to release branch.
>>>>>
>>>>> - Changes to release branches can be done by pushing a bugfix/change
>>>>> branch and asking the RM to pick it up if they are tested. Our
>>>>> automated
>>>>> systems can perform checks on such branches too (starting with a
>>>>> suffix that
>>>>> can automatically trigger such builds/tests) and if everything is
>>>>> fine, RMs to
>>>>> land the changes to release branches.
>>>>>
>>>>> - Nothing is written in stones, this should be change-able. And, this
>>>>> can only
>>>>> work if we all agree to follow this with 4.5
>>>>>
>>>>> To make the best of this thread, please keep your reply short,
>>>>> constructive
>>>>> and to the point..
>>>>> Please share your opinion on this proposal with suitable reasons:
>>>>>
>>>>> [ ] +1  approve
>>>>> [ ] +0  no opinion
>>>>> [ ] -1  disapprove (and reason why)
>>>>>
>>>>> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
>>>>>
>>>>> 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.
>>>
>>> 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.
>
>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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

Min,

On 18-Aug-2014, at 8:25 pm, Min Chen <mi...@citrix.com> wrote:

> Rohit,
>
> I think that Edison and I have clearly indicated our objection reason in
> our previous email. Based on current cloudstack quality, RM needs to have
> control over what commits to be in release branch to get a release at
> least having some quality. With this proposed model, how can you guarantee
> the quality of a release? We cannot just talk about changing a process
> without resolving this important concern. What is your solution to this
> concern?

In my proposal we’re not saying people “can" commit directly to release branches, I suggest you re-read the proposal. I cannot emphasis this enough that this does not try to solve the issue you’re raising (which deserves a thread of its own), so the expectation from everyone is to stick to the agenda and comment on it.

Min, I’ve said this at least four times now I feel like people are just skimming emails :P If they are, may I deserve their attention to read my email with full attention like I do when I read theirs?

We’re not giving power to everyone commit directly on release branches, so we’re not changing the status quo around this issue so there is no point of questioning “release quality”.

This sort of workflow is something used at several companies such as Google and Facebook which has turned out to work for them.

If you find any issues or challenges with this I would love to hear from you. At the end of the day as an individual wearing your Apache hat it’s your call and right to votes and opinions so we respect your votes but it would be only encouraging if they are backed by a good reason.

Lastly, I don’t have the “unicorn" solution that will guarantee quality of a release and I think perhaps it does not exist.

This proposal does not aim to solve the “release quality issue” but to:

- encourage involvement of contributors during release: My personal opinion is that we’ve a major problem that unless a commercial distribution’s releases is based on ACS release, many of the “sponsored” developers won’t participate much in opensource ACS releasess. How do we solve it? I guess we need some way to increase participation, by increasing participation we’ll have much better release quality than perhaps that will less involvement.
- a guideline to reduce conflicts and make sure no commit is missed or misplaced
- give a flow of change (baseline protocol) on how to maintain multiple release branches

Min and others, I would welcome if you’ve any issues or challenges you can find with “what” the above will try to implement.

Cheers.


>
> Thanks
> -min
>
>
> On 8/18/14 10:59 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>
>> Hi,
>>
>> @Jessica ‹ Can you please suggest what¹s wrong with the ³things² that
>> were proposed here as I could not figure out your or Min¹s or Edison's
>> individual opinion and reason behind the vote.
>>
>> We have three -1s (1 binding) but none of them share valid reasons or
>> concerns that would point out issues and challenges with adopting the
>> proposed items so we¹ll continue with the voting.
>>
>> Min, Jessica, Edison ‹ I would love to know what¹s wrong in the "proposed
>> things" so we don¹t make mistake.
>>
>> @Rajani ‹ Thanks, but when we should cut a release branch is a different
>> topic and IMO is per the RM¹s discretion so if you¹ve any ideas or
>> proposals please go ahead and start a thread on that.
>>
>> Cheers.
>>
>> On 18-Aug-2014, at 6:52 pm, Jessica Wang <Je...@citrix.com> wrote:
>>
>>> I agree with Edison.
>>> I am -1 on this as well.
>>>
>>>
>>> -----Original Message-----
>>> From: Edison Su [mailto:Edison.su@citrix.com]
>>> Sent: Saturday, August 16, 2014 12:11 PM
>>> To: dev
>>> Subject: RE: [VOTE] Adapting git workflow for release branches
>>>
>>> I agree with what Min said on thread:
>>> http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with
>>> your answer:
>>> Currently we don't have a CI running continuously, no code review, it's
>>> too risky to let developer check in whatever commit they want into
>>> release branch. RM needs to have to control over what commit should be
>>> put into release branch and what should not, otherwise, we could get
>>> into a stage where no control on the quality.
>>> How RM will do the control, that's something we could discuss. I know,
>>> current model is not scale, as RM needs to manually cherry pick commits
>>> into release branch. The way I thinking about, is all the commits put
>>> into release branch, must be put into review board, or gerrit, must be
>>> passed by CI and reviewers, then the commits can be put into release
>>> branch.
>>> For above reason, I am -1(binding) on your proposal for now until we
>>> solve the quality control problem.
>>>
>>>> -----Original Message-----
>>>> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
>>>> Sent: Friday, August 15, 2014 3:25 AM
>>>> To: dev
>>>> Subject: [VOTE] Adapting git workflow for release branches
>>>>
>>>> Hello everyone,
>>>>
>>>> With reference to my proposal on changing our release-master commit
>>>> flow
>>>> [1], I would like to start a voting thread to decide on the adoption
>>>> starting 4.5
>>>> release. Any opinion, ideas, modifications is welcome to help reach a
>>>> consensus and improve our present situation.
>>>>
>>>> Today's Friday so it will be only fair to extend the voting window to
>>>> more
>>>> than our usual 72 hours window.
>>>> Therefore, we'll end this voting on Wednesday, 20 August 2014 at 18:00H
>>>> UTC giving about 5 days of time for people to share what works and what
>>>> does not. We'll stop anytime we've three -1s (binding).
>>>>
>>>> Short summary:
>>>>
>>>> - Base line protocol: Continuous changes from release/stable branches
>>>> to
>>>> master/unable branches
>>>> - Get contributors more engaged with release branches by working
>>>> (fixing
>>>> bugs, docs etc.) on release branches first (and not on master)
>>>> - Fixes on release branches are recommended (non strict enforcement) go
>>>> via a hotfix/bugfix branch that get automatically tested by Jenkins,
>>>> when
>>>> they are green RMs get the changes to release branch
>>>>
>>>> Long Summary of what we'll adopt: (I'm skipping writing them on wiki,
>>>> as this
>>>> may change/modify in this thread)
>>>>
>>>> - Continuous flow of changes from stable branches to un-stables ones
>>>> i.e.
>>>> from release branches to master and from master to features etc. Use of
>>>> merge -fast-forward is encourages over cherry-picking and -no-ff (no ff
>>>> will create merge commit). This happens couple of times a day to
>>>> ensure we
>>>> get solid/robust changes from release branches (such as bugfixes etc.)
>>>> on
>>>> master, any conflicts will be resolved. If we do it continuously we'll
>>>> also save
>>>> ourselves from a big conflict at the end of the release cycle and
>>>> we'll also
>>>> avoid missing/misplacing any commit when cherry-picking.
>>>>
>>>> - After code freeze is declared and release branch is cut out,
>>>> contributors
>>>> work on fixing bugs and other changes (such as documentation,
>>>> build/packaging fixes etc.) first on the release branch (and not
>>>> master). This
>>>> is not to restrict anyone working on master, features and other
>>>> changes can
>>>> keep landing on master as well. This is to encourage contributors to
>>>> give
>>>> more attention to release branches by at least fixing bugs on release
>>>> branches first and not our current way where we fix it on master and
>>>> ask
>>>> RMs to cherry pick it to release branch.
>>>>
>>>> - Changes to release branches can be done by pushing a bugfix/change
>>>> branch and asking the RM to pick it up if they are tested. Our
>>>> automated
>>>> systems can perform checks on such branches too (starting with a
>>>> suffix that
>>>> can automatically trigger such builds/tests) and if everything is
>>>> fine, RMs to
>>>> land the changes to release branches.
>>>>
>>>> - Nothing is written in stones, this should be change-able. And, this
>>>> can only
>>>> work if we all agree to follow this with 4.5
>>>>
>>>> To make the best of this thread, please keep your reply short,
>>>> constructive
>>>> and to the point..
>>>> Please share your opinion on this proposal with suitable reasons:
>>>>
>>>> [ ] +1  approve
>>>> [ ] +0  no opinion
>>>> [ ] -1  disapprove (and reason why)
>>>>
>>>> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
>>>>
>>>> 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.
>>
>> 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.

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: [VOTE] Adapting git workflow for release branches

[Min Chen <mi...@citrix.com>]

Rohit,

	I think that Edison and I have clearly indicated our objection reason in
our previous email. Based on current cloudstack quality, RM needs to have
control over what commits to be in release branch to get a release at
least having some quality. With this proposed model, how can you guarantee
the quality of a release? We cannot just talk about changing a process
without resolving this important concern. What is your solution to this
concern?

	Thanks
	-min


On 8/18/14 10:59 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:

>Hi,
>
>@Jessica ‹ Can you please suggest what¹s wrong with the ³things² that
>were proposed here as I could not figure out your or Min¹s or Edison's
>individual opinion and reason behind the vote.
>
>We have three -1s (1 binding) but none of them share valid reasons or
>concerns that would point out issues and challenges with adopting the
>proposed items so we¹ll continue with the voting.
>
>Min, Jessica, Edison ‹ I would love to know what¹s wrong in the "proposed
>things" so we don¹t make mistake.
>
>@Rajani ‹ Thanks, but when we should cut a release branch is a different
>topic and IMO is per the RM¹s discretion so if you¹ve any ideas or
>proposals please go ahead and start a thread on that.
>
>Cheers.
>
>On 18-Aug-2014, at 6:52 pm, Jessica Wang <Je...@citrix.com> wrote:
>
>> I agree with Edison.
>> I am -1 on this as well.
>>
>>
>> -----Original Message-----
>> From: Edison Su [mailto:Edison.su@citrix.com]
>> Sent: Saturday, August 16, 2014 12:11 PM
>> To: dev
>> Subject: RE: [VOTE] Adapting git workflow for release branches
>>
>> I agree with what Min said on thread:
>>http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with
>>your answer:
>> Currently we don't have a CI running continuously, no code review, it's
>>too risky to let developer check in whatever commit they want into
>>release branch. RM needs to have to control over what commit should be
>>put into release branch and what should not, otherwise, we could get
>>into a stage where no control on the quality.
>> How RM will do the control, that's something we could discuss. I know,
>>current model is not scale, as RM needs to manually cherry pick commits
>>into release branch. The way I thinking about, is all the commits put
>>into release branch, must be put into review board, or gerrit, must be
>>passed by CI and reviewers, then the commits can be put into release
>>branch.
>> For above reason, I am -1(binding) on your proposal for now until we
>>solve the quality control problem.
>>
>>> -----Original Message-----
>>> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
>>> Sent: Friday, August 15, 2014 3:25 AM
>>> To: dev
>>> Subject: [VOTE] Adapting git workflow for release branches
>>>
>>> Hello everyone,
>>>
>>> With reference to my proposal on changing our release-master commit
>>>flow
>>> [1], I would like to start a voting thread to decide on the adoption
>>>starting 4.5
>>> release. Any opinion, ideas, modifications is welcome to help reach a
>>> consensus and improve our present situation.
>>>
>>> Today's Friday so it will be only fair to extend the voting window to
>>>more
>>> than our usual 72 hours window.
>>> Therefore, we'll end this voting on Wednesday, 20 August 2014 at 18:00H
>>> UTC giving about 5 days of time for people to share what works and what
>>> does not. We'll stop anytime we've three -1s (binding).
>>>
>>> Short summary:
>>>
>>> - Base line protocol: Continuous changes from release/stable branches
>>>to
>>> master/unable branches
>>> - Get contributors more engaged with release branches by working
>>>(fixing
>>> bugs, docs etc.) on release branches first (and not on master)
>>> - Fixes on release branches are recommended (non strict enforcement) go
>>> via a hotfix/bugfix branch that get automatically tested by Jenkins,
>>>when
>>> they are green RMs get the changes to release branch
>>>
>>> Long Summary of what we'll adopt: (I'm skipping writing them on wiki,
>>>as this
>>> may change/modify in this thread)
>>>
>>> - Continuous flow of changes from stable branches to un-stables ones
>>>i.e.
>>> from release branches to master and from master to features etc. Use of
>>> merge -fast-forward is encourages over cherry-picking and -no-ff (no ff
>>> will create merge commit). This happens couple of times a day to
>>>ensure we
>>> get solid/robust changes from release branches (such as bugfixes etc.)
>>>on
>>> master, any conflicts will be resolved. If we do it continuously we'll
>>>also save
>>> ourselves from a big conflict at the end of the release cycle and
>>>we'll also
>>> avoid missing/misplacing any commit when cherry-picking.
>>>
>>> - After code freeze is declared and release branch is cut out,
>>>contributors
>>> work on fixing bugs and other changes (such as documentation,
>>> build/packaging fixes etc.) first on the release branch (and not
>>>master). This
>>> is not to restrict anyone working on master, features and other
>>>changes can
>>> keep landing on master as well. This is to encourage contributors to
>>>give
>>> more attention to release branches by at least fixing bugs on release
>>> branches first and not our current way where we fix it on master and
>>>ask
>>> RMs to cherry pick it to release branch.
>>>
>>> - Changes to release branches can be done by pushing a bugfix/change
>>> branch and asking the RM to pick it up if they are tested. Our
>>>automated
>>> systems can perform checks on such branches too (starting with a
>>>suffix that
>>> can automatically trigger such builds/tests) and if everything is
>>>fine, RMs to
>>> land the changes to release branches.
>>>
>>> - Nothing is written in stones, this should be change-able. And, this
>>>can only
>>> work if we all agree to follow this with 4.5
>>>
>>> To make the best of this thread, please keep your reply short,
>>>constructive
>>> and to the point..
>>> Please share your opinion on this proposal with suitable reasons:
>>>
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>>
>>> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
>>>
>>> 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.
>
>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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

Hi,

@Jessica — Can you please suggest what’s wrong with the “things” that were proposed here as I could not figure out your or Min’s or Edison's individual opinion and reason behind the vote.

We have three -1s (1 binding) but none of them share valid reasons or concerns that would point out issues and challenges with adopting the proposed items so we’ll continue with the voting.

Min, Jessica, Edison — I would love to know what’s wrong in the "proposed things" so we don’t make mistake.

@Rajani — Thanks, but when we should cut a release branch is a different topic and IMO is per the RM’s discretion so if you’ve any ideas or proposals please go ahead and start a thread on that.

Cheers.

On 18-Aug-2014, at 6:52 pm, Jessica Wang <Je...@citrix.com> wrote:

> I agree with Edison.
> I am -1 on this as well.
>
>
> -----Original Message-----
> From: Edison Su [mailto:Edison.su@citrix.com]
> Sent: Saturday, August 16, 2014 12:11 PM
> To: dev
> Subject: RE: [VOTE] Adapting git workflow for release branches
>
> I agree with what Min said on thread: http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with your answer:
> Currently we don't have a CI running continuously, no code review, it's too risky to let developer check in whatever commit they want into release branch. RM needs to have to control over what commit should be put into release branch and what should not, otherwise, we could get into a stage where no control on the quality.
> How RM will do the control, that's something we could discuss. I know, current model is not scale, as RM needs to manually cherry pick commits into release branch. The way I thinking about, is all the commits put into release branch, must be put into review board, or gerrit, must be passed by CI and reviewers, then the commits can be put into release branch.
> For above reason, I am -1(binding) on your proposal for now until we solve the quality control problem.
>
>> -----Original Message-----
>> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
>> Sent: Friday, August 15, 2014 3:25 AM
>> To: dev
>> Subject: [VOTE] Adapting git workflow for release branches
>>
>> Hello everyone,
>>
>> With reference to my proposal on changing our release-master commit flow
>> [1], I would like to start a voting thread to decide on the adoption starting 4.5
>> release. Any opinion, ideas, modifications is welcome to help reach a
>> consensus and improve our present situation.
>>
>> Today's Friday so it will be only fair to extend the voting window to more
>> than our usual 72 hours window.
>> Therefore, we'll end this voting on Wednesday, 20 August 2014 at 18:00H
>> UTC giving about 5 days of time for people to share what works and what
>> does not. We'll stop anytime we've three -1s (binding).
>>
>> Short summary:
>>
>> - Base line protocol: Continuous changes from release/stable branches to
>> master/unable branches
>> - Get contributors more engaged with release branches by working (fixing
>> bugs, docs etc.) on release branches first (and not on master)
>> - Fixes on release branches are recommended (non strict enforcement) go
>> via a hotfix/bugfix branch that get automatically tested by Jenkins, when
>> they are green RMs get the changes to release branch
>>
>> Long Summary of what we'll adopt: (I'm skipping writing them on wiki, as this
>> may change/modify in this thread)
>>
>> - Continuous flow of changes from stable branches to un-stables ones i.e.
>> from release branches to master and from master to features etc. Use of
>> merge -fast-forward is encourages over cherry-picking and -no-ff (no ff
>> will create merge commit). This happens couple of times a day to ensure we
>> get solid/robust changes from release branches (such as bugfixes etc.) on
>> master, any conflicts will be resolved. If we do it continuously we'll also save
>> ourselves from a big conflict at the end of the release cycle and we'll also
>> avoid missing/misplacing any commit when cherry-picking.
>>
>> - After code freeze is declared and release branch is cut out, contributors
>> work on fixing bugs and other changes (such as documentation,
>> build/packaging fixes etc.) first on the release branch (and not master). This
>> is not to restrict anyone working on master, features and other changes can
>> keep landing on master as well. This is to encourage contributors to give
>> more attention to release branches by at least fixing bugs on release
>> branches first and not our current way where we fix it on master and ask
>> RMs to cherry pick it to release branch.
>>
>> - Changes to release branches can be done by pushing a bugfix/change
>> branch and asking the RM to pick it up if they are tested. Our automated
>> systems can perform checks on such branches too (starting with a suffix that
>> can automatically trigger such builds/tests) and if everything is fine, RMs to
>> land the changes to release branches.
>>
>> - Nothing is written in stones, this should be change-able. And, this can only
>> work if we all agree to follow this with 4.5
>>
>> To make the best of this thread, please keep your reply short, constructive
>> and to the point..
>> Please share your opinion on this proposal with suitable reasons:
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
>>
>> 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.

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: [VOTE] Adapting git workflow for release branches

[Jessica Wang <Je...@citrix.com>]

I agree with Edison.
I am -1 on this as well.


-----Original Message-----
From: Edison Su [mailto:Edison.su@citrix.com] 
Sent: Saturday, August 16, 2014 12:11 PM
To: dev
Subject: RE: [VOTE] Adapting git workflow for release branches

I agree with what Min said on thread: http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with your answer:
Currently we don't have a CI running continuously, no code review, it's too risky to let developer check in whatever commit they want into release branch. RM needs to have to control over what commit should be put into release branch and what should not, otherwise, we could get into a stage where no control on the quality.
How RM will do the control, that's something we could discuss. I know, current model is not scale, as RM needs to manually cherry pick commits into release branch. The way I thinking about, is all the commits put into release branch, must be put into review board, or gerrit, must be passed by CI and reviewers, then the commits can be put into release branch. 
For above reason, I am -1(binding) on your proposal for now until we solve the quality control problem. 

> -----Original Message-----
> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> Sent: Friday, August 15, 2014 3:25 AM
> To: dev
> Subject: [VOTE] Adapting git workflow for release branches
> 
> Hello everyone,
> 
> With reference to my proposal on changing our release-master commit flow
> [1], I would like to start a voting thread to decide on the adoption starting 4.5
> release. Any opinion, ideas, modifications is welcome to help reach a
> consensus and improve our present situation.
> 
> Today's Friday so it will be only fair to extend the voting window to more
> than our usual 72 hours window.
> Therefore, we'll end this voting on Wednesday, 20 August 2014 at 18:00H
> UTC giving about 5 days of time for people to share what works and what
> does not. We'll stop anytime we've three -1s (binding).
> 
> Short summary:
> 
> - Base line protocol: Continuous changes from release/stable branches to
> master/unable branches
> - Get contributors more engaged with release branches by working (fixing
> bugs, docs etc.) on release branches first (and not on master)
> - Fixes on release branches are recommended (non strict enforcement) go
> via a hotfix/bugfix branch that get automatically tested by Jenkins, when
> they are green RMs get the changes to release branch
> 
> Long Summary of what we'll adopt: (I'm skipping writing them on wiki, as this
> may change/modify in this thread)
> 
> - Continuous flow of changes from stable branches to un-stables ones i.e.
> from release branches to master and from master to features etc. Use of
> merge -fast-forward is encourages over cherry-picking and -no-ff (no ff
> will create merge commit). This happens couple of times a day to ensure we
> get solid/robust changes from release branches (such as bugfixes etc.) on
> master, any conflicts will be resolved. If we do it continuously we'll also save
> ourselves from a big conflict at the end of the release cycle and we'll also
> avoid missing/misplacing any commit when cherry-picking.
> 
> - After code freeze is declared and release branch is cut out, contributors
> work on fixing bugs and other changes (such as documentation,
> build/packaging fixes etc.) first on the release branch (and not master). This
> is not to restrict anyone working on master, features and other changes can
> keep landing on master as well. This is to encourage contributors to give
> more attention to release branches by at least fixing bugs on release
> branches first and not our current way where we fix it on master and ask
> RMs to cherry pick it to release branch.
> 
> - Changes to release branches can be done by pushing a bugfix/change
> branch and asking the RM to pick it up if they are tested. Our automated
> systems can perform checks on such branches too (starting with a suffix that
> can automatically trigger such builds/tests) and if everything is fine, RMs to
> land the changes to release branches.
> 
> - Nothing is written in stones, this should be change-able. And, this can only
> work if we all agree to follow this with 4.5
> 
> To make the best of this thread, please keep your reply short, constructive
> and to the point..
> Please share your opinion on this proposal with suitable reasons:
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
> 
> 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: [VOTE] Adapting git workflow for release branches

[Min Chen <mi...@citrix.com>]

I  am -1 on this as well. Any git process change needs to be considered together with the quality problem we are facing now, which i believe that it is the root cause for RM manual cherry pick issue. We cannot just adopt a process by ignoring its root quality problem. Sorry that your answer here still cannot satisfy me.

Thanks
-min

Sent from my iPhone

> On Aug 16, 2014, at 2:32 PM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
> 
> Hi Edison,
> 
> Thank you for your email, I suggest you read my reply to Min’s email as well: http://markmail.org/message/vytkbqhdjmhewonl
> 
> Let me begin by saying that perhaps I was unable to capture everyone’s imagination with my proposal, I’ll work on my writing skills and try to keep them short and objective.
> 
> I think I’ve an answer to satisfy your worries but if at the end of reading this email you’re not satisfied, instead of going back and forth on this thread we could talk on phone, Skype, GTM etc. (whatever is convenient for you, my contact details can be found in my signature).
> 
> Now, this voting thread (and also in the proposal thread) has nothing to do with "enforcing quality", but has:
> 
> 1. Change of flow: Get people more involved with release branches: get their stuff to release branches first via a hotfix/bugfix branch and then merge -ff (or cherry-pick) to master, feature branches etc.
> 
> 2. Baseline protocol: Give a guideline for contributors on how to fix something that spans multiple releases and branches, for example starting with oldest version/release (firm) to latest and then to master (soft) etc.
> 
> Since, I’m not trying to solve any “quality control” issue, I cannot take the responsibility of trying to fix anything around it as well. Therefore, it will be only fair if you could re-read what we’re voting on and return back with your unbiased, individual and objective opinion.
> 
>> On 16-Aug-2014, at 9:10 pm, Edison Su <Ed...@citrix.com> wrote:
>> 
>> How RM will do the control, that's something we could discuss. I know, current model is not scale, as RM needs to manually cherry pick commits into release branch. The way I thinking about, is all the commits put into release branch, must be put into review board, or gerrit, must be passed by CI and reviewers, then the commits can be put into release branch.
> 
> Good ideas, I think you should start a proposal thread and help with actionable items. At present, I’m not trying to address the aforementioned challenges because it will be tricky and I don’t have a solution. This will be important for us but will be challenging, IMHO will be time taking and call for:
> 
> - getting everyone’s agreement
> - a change of culture
> - requirement of infrastructure
> - expecting everyone learning to use the new system and workflow
> - workflow enforcement and policing
> 
> I think we do have (some) CI solutions, I may be wrong but I recall Hugo made some build job to trigger on all branches starting with “hotfix” or some prefix, so we do have such things. This week, Ian and Sebastien found a cheap way of having a CI for testing with simulator on TravisCI which is free (as in cost).
> 
>> For above reason, I am -1(binding) on your proposal for now until we solve the quality control problem.
> 
> Thank you for your vote, it’s important that we don’t make a mistake. But since the reason mentioned had nothing to do with the voting proposal I would welcome your reconsideration.
> 
> Cheers,
> 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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

Hi Edison,

in-lin;

On 18-Aug-2014, at 9:04 pm, Edison Su <Ed...@citrix.com> wrote:
> It's exactly the problem I have, I still not quite understand what's your intention to change the work flow?
> What's the problem you trying to solve?
> In your proposed git flow, there is no release-forward branch, only release branch, but bugfix/hotfix commit needs to have its own branch based on release branch,
> Then RM still needs to manually merge --ff or cherry pick into release branch in order to control quality, right?
> Am I right about your proposed git flow? If not, please let me know.
> If my understanding about your proposal is correct, then I think current release forward branch is simpler for developer and RM, for the following reasons:
> 1. developer doesn't need to create a branch for every single hotfix/bugfix, it's easier for developer.
> 2. For RM, it's easier to move forward the release branch than your proposal. For example, if there are 10 bugfixes need
> To be merged into release branch. In the current model, RM can just "git rebase", but in your model, RM has to manually merge/cherry-pick this 10 bugfixes.
> IMHO, the each bugfix/hotfix per branch model, will, maybe only, shine if there is a gerrit or code review system which can automatically merge bugfix branch into release branch, if bugfix branch passed CI/reviewer.
> Unfortunately, we may never ever have this kind of quality control in Apache CloudStack…

Please read my proposal and reply to MIn regarding this. There is no strictness around how you want to do bugfixes so I want you to take this as a guideline. For example, one can do 10s of bugfixes in a branch and ask RM to review and merge on release branch and that is alright.

The important thing is that they don’t fix it on master for all the bugfixes that qualify for the release branch though they will be free to merge other things on master such as feature work and other fixes that has nothing to do with the release branch. For non-committers reviewboard will be the way.

With this I’m trying to get more people including sponsored developers interested in release branches and the release process.
Getting people to follow a baseline protocol based workflow would help support multiple release branches in the long run as we could maintain something like a LTS release.

Cheers.

>
>
>>
>> 2. Baseline protocol: Give a guideline for contributors on how to fix
>> something that spans multiple releases and branches, for example starting
>> with oldest version/release (firm) to latest and then to master (soft) etc.
>>
>> Since, I'm not trying to solve any "quality control" issue, I cannot take the
>> responsibility of trying to fix anything around it as well. Therefore, it will be
>> only fair if you could re-read what we're voting on and return back with your
>> unbiased, individual and objective opinion.
>>
>> On 16-Aug-2014, at 9:10 pm, Edison Su <Ed...@citrix.com> wrote:
>>
>>> How RM will do the control, that's something we could discuss. I know,
>> current model is not scale, as RM needs to manually cherry pick commits into
>> release branch. The way I thinking about, is all the commits put into release
>> branch, must be put into review board, or gerrit, must be passed by CI and
>> reviewers, then the commits can be put into release branch.
>>
>> Good ideas, I think you should start a proposal thread and help with
>> actionable items. At present, I'm not trying to address the aforementioned
>> challenges because it will be tricky and I don't have a solution. This will be
>> important for us but will be challenging, IMHO will be time taking and call for:
>>
>> - getting everyone's agreement
>> - a change of culture
>> - requirement of infrastructure
>> - expecting everyone learning to use the new system and workflow
>> - workflow enforcement and policing
>>
>> I think we do have (some) CI solutions, I may be wrong but I recall Hugo
>> made some build job to trigger on all branches starting with "hotfix" or some
>> prefix, so we do have such things. This week, Ian and Sebastien found a
>> cheap way of having a CI for testing with simulator on TravisCI which is free
>> (as in cost).
>>
>>> For above reason, I am -1(binding) on your proposal for now until we solve
>> the quality control problem.
>>
>> Thank you for your vote, it's important that we don't make a mistake. But
>> since the reason mentioned had nothing to do with the voting proposal I
>> would welcome your reconsideration.
>>
>> Cheers,
>> 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.

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: [VOTE] Adapting git workflow for release branches

[Edison Su <Ed...@citrix.com>]

> -----Original Message-----
> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> Sent: Saturday, August 16, 2014 2:32 PM
> To: dev@cloudstack.apache.org
> Cc: Edison Su
> Subject: Re: [VOTE] Adapting git workflow for release branches
> 
> Hi Edison,
> 
> Thank you for your email, I suggest you read my reply to Min's email as well:
> http://markmail.org/message/vytkbqhdjmhewonl
> 
> Let me begin by saying that perhaps I was unable to capture everyone's
> imagination with my proposal, I'll work on my writing skills and try to keep
> them short and objective.
> 
> I think I've an answer to satisfy your worries but if at the end of reading this
> email you're not satisfied, instead of going back and forth on this thread we
> could talk on phone, Skype, GTM etc. (whatever is convenient for you, my
> contact details can be found in my signature).
> 
> Now, this voting thread (and also in the proposal thread) has nothing to do
> with "enforcing quality", but has:
> 
> 1. Change of flow: Get people more involved with release branches: get their
> stuff to release branches first via a hotfix/bugfix branch and then merge -ff
> (or cherry-pick) to master, feature branches etc.

It's exactly the problem I have, I still not quite understand what's your intention to change the work flow?
What's the problem you trying to solve? 
In your proposed git flow, there is no release-forward branch, only release branch, but bugfix/hotfix commit needs to have its own branch based on release branch,
Then RM still needs to manually merge --ff or cherry pick into release branch in order to control quality, right?
Am I right about your proposed git flow? If not, please let me know.
If my understanding about your proposal is correct, then I think current release forward branch is simpler for developer and RM, for the following reasons:
1. developer doesn't need to create a branch for every single hotfix/bugfix, it's easier for developer.
2. For RM, it's easier to move forward the release branch than your proposal. For example, if there are 10 bugfixes need
To be merged into release branch. In the current model, RM can just "git rebase", but in your model, RM has to manually merge/cherry-pick this 10 bugfixes.
IMHO, the each bugfix/hotfix per branch model, will, maybe only, shine if there is a gerrit or code review system which can automatically merge bugfix branch into release branch, if bugfix branch passed CI/reviewer.
Unfortunately, we may never ever have this kind of quality control in Apache CloudStack...


> 
> 2. Baseline protocol: Give a guideline for contributors on how to fix
> something that spans multiple releases and branches, for example starting
> with oldest version/release (firm) to latest and then to master (soft) etc.
> 
> Since, I'm not trying to solve any "quality control" issue, I cannot take the
> responsibility of trying to fix anything around it as well. Therefore, it will be
> only fair if you could re-read what we're voting on and return back with your
> unbiased, individual and objective opinion.
> 
> On 16-Aug-2014, at 9:10 pm, Edison Su <Ed...@citrix.com> wrote:
> 
> > How RM will do the control, that's something we could discuss. I know,
> current model is not scale, as RM needs to manually cherry pick commits into
> release branch. The way I thinking about, is all the commits put into release
> branch, must be put into review board, or gerrit, must be passed by CI and
> reviewers, then the commits can be put into release branch.
> 
> Good ideas, I think you should start a proposal thread and help with
> actionable items. At present, I'm not trying to address the aforementioned
> challenges because it will be tricky and I don't have a solution. This will be
> important for us but will be challenging, IMHO will be time taking and call for:
> 
> - getting everyone's agreement
> - a change of culture
> - requirement of infrastructure
> - expecting everyone learning to use the new system and workflow
> - workflow enforcement and policing
> 
> I think we do have (some) CI solutions, I may be wrong but I recall Hugo
> made some build job to trigger on all branches starting with "hotfix" or some
> prefix, so we do have such things. This week, Ian and Sebastien found a
> cheap way of having a CI for testing with simulator on TravisCI which is free
> (as in cost).
> 
> > For above reason, I am -1(binding) on your proposal for now until we solve
> the quality control problem.
> 
> Thank you for your vote, it's important that we don't make a mistake. But
> since the reason mentioned had nothing to do with the voting proposal I
> would welcome your reconsideration.
> 
> Cheers,
> 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: [VOTE] Adapting git workflow for release branches

[Rohit Yadav <ro...@shapeblue.com>]

Hi Edison,

Thank you for your email, I suggest you read my reply to Min’s email as well: http://markmail.org/message/vytkbqhdjmhewonl

Let me begin by saying that perhaps I was unable to capture everyone’s imagination with my proposal, I’ll work on my writing skills and try to keep them short and objective.

I think I’ve an answer to satisfy your worries but if at the end of reading this email you’re not satisfied, instead of going back and forth on this thread we could talk on phone, Skype, GTM etc. (whatever is convenient for you, my contact details can be found in my signature).

Now, this voting thread (and also in the proposal thread) has nothing to do with "enforcing quality", but has:

1. Change of flow: Get people more involved with release branches: get their stuff to release branches first via a hotfix/bugfix branch and then merge -ff (or cherry-pick) to master, feature branches etc.

2. Baseline protocol: Give a guideline for contributors on how to fix something that spans multiple releases and branches, for example starting with oldest version/release (firm) to latest and then to master (soft) etc.

Since, I’m not trying to solve any “quality control” issue, I cannot take the responsibility of trying to fix anything around it as well. Therefore, it will be only fair if you could re-read what we’re voting on and return back with your unbiased, individual and objective opinion.

On 16-Aug-2014, at 9:10 pm, Edison Su <Ed...@citrix.com> wrote:

> How RM will do the control, that's something we could discuss. I know, current model is not scale, as RM needs to manually cherry pick commits into release branch. The way I thinking about, is all the commits put into release branch, must be put into review board, or gerrit, must be passed by CI and reviewers, then the commits can be put into release branch.

Good ideas, I think you should start a proposal thread and help with actionable items. At present, I’m not trying to address the aforementioned challenges because it will be tricky and I don’t have a solution. This will be important for us but will be challenging, IMHO will be time taking and call for:

- getting everyone’s agreement
- a change of culture
- requirement of infrastructure
- expecting everyone learning to use the new system and workflow
- workflow enforcement and policing

I think we do have (some) CI solutions, I may be wrong but I recall Hugo made some build job to trigger on all branches starting with “hotfix” or some prefix, so we do have such things. This week, Ian and Sebastien found a cheap way of having a CI for testing with simulator on TravisCI which is free (as in cost).

> For above reason, I am -1(binding) on your proposal for now until we solve the quality control problem.

Thank you for your vote, it’s important that we don’t make a mistake. But since the reason mentioned had nothing to do with the voting proposal I would welcome your reconsideration.

Cheers,
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: [VOTE] Adapting git workflow for release branches

[Edison Su <Ed...@citrix.com>]

I agree with what Min said on thread: http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with your answer:
Currently we don't have a CI running continuously, no code review, it's too risky to let developer check in whatever commit they want into release branch. RM needs to have to control over what commit should be put into release branch and what should not, otherwise, we could get into a stage where no control on the quality.
How RM will do the control, that's something we could discuss. I know, current model is not scale, as RM needs to manually cherry pick commits into release branch. The way I thinking about, is all the commits put into release branch, must be put into review board, or gerrit, must be passed by CI and reviewers, then the commits can be put into release branch. 
For above reason, I am -1(binding) on your proposal for now until we solve the quality control problem. 

> -----Original Message-----
> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> Sent: Friday, August 15, 2014 3:25 AM
> To: dev
> Subject: [VOTE] Adapting git workflow for release branches
> 
> Hello everyone,
> 
> With reference to my proposal on changing our release-master commit flow
> [1], I would like to start a voting thread to decide on the adoption starting 4.5
> release. Any opinion, ideas, modifications is welcome to help reach a
> consensus and improve our present situation.
> 
> Today's Friday so it will be only fair to extend the voting window to more
> than our usual 72 hours window.
> Therefore, we'll end this voting on Wednesday, 20 August 2014 at 18:00H
> UTC giving about 5 days of time for people to share what works and what
> does not. We'll stop anytime we've three -1s (binding).
> 
> Short summary:
> 
> - Base line protocol: Continuous changes from release/stable branches to
> master/unable branches
> - Get contributors more engaged with release branches by working (fixing
> bugs, docs etc.) on release branches first (and not on master)
> - Fixes on release branches are recommended (non strict enforcement) go
> via a hotfix/bugfix branch that get automatically tested by Jenkins, when
> they are green RMs get the changes to release branch
> 
> Long Summary of what we'll adopt: (I'm skipping writing them on wiki, as this
> may change/modify in this thread)
> 
> - Continuous flow of changes from stable branches to un-stables ones i.e.
> from release branches to master and from master to features etc. Use of
> merge -fast-forward is encourages over cherry-picking and -no-ff (no ff
> will create merge commit). This happens couple of times a day to ensure we
> get solid/robust changes from release branches (such as bugfixes etc.) on
> master, any conflicts will be resolved. If we do it continuously we'll also save
> ourselves from a big conflict at the end of the release cycle and we'll also
> avoid missing/misplacing any commit when cherry-picking.
> 
> - After code freeze is declared and release branch is cut out, contributors
> work on fixing bugs and other changes (such as documentation,
> build/packaging fixes etc.) first on the release branch (and not master). This
> is not to restrict anyone working on master, features and other changes can
> keep landing on master as well. This is to encourage contributors to give
> more attention to release branches by at least fixing bugs on release
> branches first and not our current way where we fix it on master and ask
> RMs to cherry pick it to release branch.
> 
> - Changes to release branches can be done by pushing a bugfix/change
> branch and asking the RM to pick it up if they are tested. Our automated
> systems can perform checks on such branches too (starting with a suffix that
> can automatically trigger such builds/tests) and if everything is fine, RMs to
> land the changes to release branches.
> 
> - Nothing is written in stones, this should be change-able. And, this can only
> work if we all agree to follow this with 4.5
> 
> To make the best of this thread, please keep your reply short, constructive
> and to the point..
> Please share your opinion on this proposal with suitable reasons:
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> [1] http://markmail.org/message/ucixhhdbz3ajyv2a
> 
> 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.