[VOTE] git workflow

[Rajani Karuturi <Ra...@citrix.com>]

Hi All,

We had long discussions on the git flow.
I tried to capture the summary of it @ http://markmail.org/message/j5z7dxjcqxfkfhpj
This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote:

Can you share your opinion on the proposal?

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


Thanks,
~Rajani

Re: [VOTE] git workflow

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

Animesh,

There will always be developers creating conflicts or not taking into
account the semantics of other peoples code. Certainly in a worldwide
project like ACS. I see your reservation. The question is if we
improve the situation by working differently. I don't know but I think
we will. More important is that people educate themselves on the way
of working. (I am repeating myself, am I?)

regards,
Daan

On Sun, Aug 3, 2014 at 6:50 AM, Animesh Chaturvedi
<an...@citrix.com> wrote:
> +0
>
> While this protects master with only commits which are merges from release branch and keeps it clean but the issues that we have shift to develop branch.
>
>
>> -----Original Message-----
>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>> Sent: Thursday, July 31, 2014 3:28 AM
>> To: dev
>> Subject: [VOTE] git workflow
>>
>> Hi All,
>>
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @
>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>>
>> Can you share your opinion on the proposal?
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>>
>> Thanks,
>> ~Rajani
>>
>>
>



-- 
Daan

Re: [VOTE] git workflow

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

I’ll get back to you on this thread tomorrow, late night here o/

Cheers.

On 05-Aug-2014, at 11:11 pm, Alena Prokharchyk <Al...@citrix.com> wrote:

> Rohit, can you help us to figure out the advantages of implementation #2
> (git workflow way of maintaining master branch) over implementation #1? As
> per your words from other email "I was skeptic too and explored every bit
> of the workflow and usage of git and I think it’s a good model” you might
> have the answer :)
>
> See details of implementation #1 and #2 below.
>
> Thank you,
> Alena.
>
> On 8/5/14, 1:45 PM, "Alena Prokharchyk" <Al...@citrix.com>
> wrote:
>
>> Rayees,
>>
>> I think you have the same misunderstanding as a lot of other folks
>> (including myself) had in the beginning - seeing develop branch as a trunk
>> branch that gets merged into master on a regular basis after the BVT/CI
>> tests pass. So the master branch reflects the develop branch minus changes
>> that didn¹t pass the tests and weren¹t merged into master -  lets refer to
>> it as implementation #1
>>
>> That¹s not what git workflow/this thread proposes. In git workflow master
>> branch reflects the latest stable release instead. So for example, we
>> released 4.4, and that what you would see the master to be as we merge the
>> *release branch to master, not the *develop to master. And develop branch
>> becomes the trunk branch where all the new fixes go to. I would look at
>> the master as at the stable branch, where you can track the history for
>> all the major releases as for each of them the master branch has
>> corresponding tags - lets call it implementation #2
>>
>> I still don¹t see many advantages in implementation #2 - making the master
>> build stable by simply making it reflect the latest release branch.
>> Because you:
>>
>> * never cut the release from master branch
>> * if you are the customer, and need the latest stable code, you download
>> the official RPM
>> * if you are a developer, you always want to download the latest code, and
>> that comes from *develop branch
>> * if you want to look at the latest stable release, you look at the
>> release branch as per CS git workflow implementation we never remove the
>> release branches (they are needed for maintenance releases)
>>
>>
>> It would be great if anyone can point the advantages of #2 approach over
>> #1, as to me #1 seems to be the approach most people will find more
>> intuitive and its used a lot in the field.
>>
>> -Alena.
>>
>>
>>
>> On 8/5/14, 1:22 PM, "Rayees Namathponnan" <ra...@citrix.com>
>> wrote:
>>
>>> How frequent we can planning to merge from develop to master ?  during
>>> release ?
>>>
>>> Regards,
>>> Rayees
>>>
>>>
>>> -----Original Message-----
>>> From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
>>> Sent: Tuesday, August 05, 2014 11:51 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: RE: [VOTE] git workflow
>>>
>>> Sorry if this is already discussed, but few areas that are unclear to me
>>> with this process are:
>>>
>>> - does every fix, however minor it be(say a signle line), needs to be
>>> developed in a separate branch? And then we have to merge these
>>> individual branches to develop for every fix?
>>> - In that case will direct check-ins to 'develop' branch be not allowed?
>>> - If not, if CI fails on develop branch, how will one know what caused
>>> the failure? Was it some direct checkin Vs some feature/fix merged? Will
>>> we revert all the small feature/fixes that were merged to develop branch
>>> upto the CI baseline? If yes, wont the developers that did not cause the
>>> break get penalized unnecessary?
>>>
>>> - Lastly, why can't this process be implemented on master? Why are we
>>> introducing another branch for the same purposes which the master branch
>>> usually serves?
>>>
>>>
>>> I am -1 on this.  We should not start implementing this until all
>>> processes are clear.
>>>
>>> Prachi
>>>
>>> -----Original Message-----
>>> From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
>>> Sent: Tuesday, August 05, 2014 11:33 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: RE: [VOTE] git workflow
>>>
>>> Exactly. This just shifts pain from one branch to another.
>>> I don't see any gains from this, either.
>>> I vote "-1".
>>>
>>> Jessica
>>>
>>>
>>> -----Original Message-----
>>> From: Min Chen [mailto:min.chen@citrix.com]
>>> Sent: Tuesday, August 05, 2014 11:27 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [VOTE] git workflow
>>>
>>> Agree with Animesh. Didn't see any gains from this, we just shift pain
>>> from one branch to another, so vote -1.
>>>
>>> -min
>>>
>>> On 8/2/14 9:50 PM, "Animesh Chaturvedi" <an...@citrix.com>
>>> wrote:
>>>
>>>> +0
>>>>
>>>> While this protects master with only commits which are merges from
>>>> release branch and keeps it clean but the issues that we have shift to
>>>> develop branch.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>>>>> Sent: Thursday, July 31, 2014 3:28 AM
>>>>> To: dev
>>>>> Subject: [VOTE] git workflow
>>>>>
>>>>> Hi All,
>>>>>
>>>>> We had long discussions on the git flow.
>>>>> I tried to capture the summary of it @
>>>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>>>> This is updated on wiki @
>>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>>>>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>>>>>
>>>>> Can you share your opinion on the proposal?
>>>>>
>>>>> [ ] +1  approve
>>>>> [ ] +0  no opinion
>>>>> [ ] -1  disapprove (and reason why)
>>>>>
>>>>>
>>>>> Thanks,
>>>>> ~Rajani
>>>>>
>>>>>
>>>>
>>>
>>
>

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] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Rohit, can you help us to figure out the advantages of implementation #2
(git workflow way of maintaining master branch) over implementation #1? As
per your words from other email "I was skeptic too and explored every bit
of the workflow and usage of git and I think it’s a good model” you might
have the answer :)

See details of implementation #1 and #2 below.

Thank you,
Alena.

On 8/5/14, 1:45 PM, "Alena Prokharchyk" <Al...@citrix.com>
wrote:

>Rayees, 
>
>I think you have the same misunderstanding as a lot of other folks
>(including myself) had in the beginning - seeing develop branch as a trunk
>branch that gets merged into master on a regular basis after the BVT/CI
>tests pass. So the master branch reflects the develop branch minus changes
>that didn¹t pass the tests and weren¹t merged into master -  lets refer to
>it as implementation #1
>
>That¹s not what git workflow/this thread proposes. In git workflow master
>branch reflects the latest stable release instead. So for example, we
>released 4.4, and that what you would see the master to be as we merge the
>*release branch to master, not the *develop to master. And develop branch
>becomes the trunk branch where all the new fixes go to. I would look at
>the master as at the stable branch, where you can track the history for
>all the major releases as for each of them the master branch has
>corresponding tags - lets call it implementation #2
>
>I still don¹t see many advantages in implementation #2 - making the master
>build stable by simply making it reflect the latest release branch.
>Because you:
>
>* never cut the release from master branch
>* if you are the customer, and need the latest stable code, you download
>the official RPM
>* if you are a developer, you always want to download the latest code, and
>that comes from *develop branch
>* if you want to look at the latest stable release, you look at the
>release branch as per CS git workflow implementation we never remove the
>release branches (they are needed for maintenance releases)
>
>
>It would be great if anyone can point the advantages of #2 approach over
>#1, as to me #1 seems to be the approach most people will find more
>intuitive and its used a lot in the field.
>
>-Alena.
>
>
>
>On 8/5/14, 1:22 PM, "Rayees Namathponnan" <ra...@citrix.com>
>wrote:
>
>>How frequent we can planning to merge from develop to master ?  during
>>release ?   
>>
>>Regards,
>>Rayees 
>>
>>
>>-----Original Message-----
>>From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
>>Sent: Tuesday, August 05, 2014 11:51 AM
>>To: dev@cloudstack.apache.org
>>Subject: RE: [VOTE] git workflow
>>
>>Sorry if this is already discussed, but few areas that are unclear to me
>>with this process are:
>>
>>- does every fix, however minor it be(say a signle line), needs to be
>>developed in a separate branch? And then we have to merge these
>>individual branches to develop for every fix?
>>- In that case will direct check-ins to 'develop' branch be not allowed?
>>- If not, if CI fails on develop branch, how will one know what caused
>>the failure? Was it some direct checkin Vs some feature/fix merged? Will
>>we revert all the small feature/fixes that were merged to develop branch
>>upto the CI baseline? If yes, wont the developers that did not cause the
>>break get penalized unnecessary?
>>
>>- Lastly, why can't this process be implemented on master? Why are we
>>introducing another branch for the same purposes which the master branch
>>usually serves?
>>
>>
>>I am -1 on this.  We should not start implementing this until all
>>processes are clear.
>>
>>Prachi
>>
>>-----Original Message-----
>>From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
>>Sent: Tuesday, August 05, 2014 11:33 AM
>>To: dev@cloudstack.apache.org
>>Subject: RE: [VOTE] git workflow
>>
>>Exactly. This just shifts pain from one branch to another.
>>I don't see any gains from this, either.
>>I vote "-1".
>>
>>Jessica
>>
>>
>>-----Original Message-----
>>From: Min Chen [mailto:min.chen@citrix.com]
>>Sent: Tuesday, August 05, 2014 11:27 AM
>>To: dev@cloudstack.apache.org
>>Subject: Re: [VOTE] git workflow
>>
>>Agree with Animesh. Didn't see any gains from this, we just shift pain
>>from one branch to another, so vote -1.
>>
>>-min
>>
>>On 8/2/14 9:50 PM, "Animesh Chaturvedi" <an...@citrix.com>
>>wrote:
>>
>>>+0
>>>
>>>While this protects master with only commits which are merges from
>>>release branch and keeps it clean but the issues that we have shift to
>>>develop branch.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>>>> Sent: Thursday, July 31, 2014 3:28 AM
>>>> To: dev
>>>> Subject: [VOTE] git workflow
>>>> 
>>>> Hi All,
>>>> 
>>>> We had long discussions on the git flow.
>>>> I tried to capture the summary of it @
>>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>>> This is updated on wiki @
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>>>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>>>> 
>>>> Can you share your opinion on the proposal?
>>>> 
>>>> [ ] +1  approve
>>>> [ ] +0  no opinion
>>>> [ ] -1  disapprove (and reason why)
>>>> 
>>>> 
>>>> Thanks,
>>>> ~Rajani
>>>> 
>>>> 
>>>
>>
>

Re: [VOTE] git workflow

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

I think the core difference between your implementations is that #1 assumes
that BVT/CI will catch 100% of errors, resulting in a stable master branch
with no problems. Or that development changes can be blindly merged if they
pass CI. The goal of git-flow is to allow a stream of development changes
that don't impact the stable release or process, and the process of making
a release is assumed to take a separate effort and cleanup.

The other major benefit that I think is getting missed by having a stable
master branch is an ease with creating hotfixes. Sure, you can branch from
a tag in a development branch, but it feels cleaner to me to branch from
the release branch and then selectively merge back into any other affected
areas.


On Tue, Aug 5, 2014 at 3:45 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> Rayees,
>
> I think you have the same misunderstanding as a lot of other folks
> (including myself) had in the beginning - seeing develop branch as a trunk
> branch that gets merged into master on a regular basis after the BVT/CI
> tests pass. So the master branch reflects the develop branch minus changes
> that didn¹t pass the tests and weren¹t merged into master -  lets refer to
> it as implementation #1
>
> That¹s not what git workflow/this thread proposes. In git workflow master
> branch reflects the latest stable release instead. So for example, we
> released 4.4, and that what you would see the master to be as we merge the
> *release branch to master, not the *develop to master. And develop branch
> becomes the trunk branch where all the new fixes go to. I would look at
> the master as at the stable branch, where you can track the history for
> all the major releases as for each of them the master branch has
> corresponding tags - lets call it implementation #2
>
> I still don¹t see many advantages in implementation #2 - making the master
> build stable by simply making it reflect the latest release branch.
> Because you:
>
> * never cut the release from master branch
> * if you are the customer, and need the latest stable code, you download
> the official RPM
> * if you are a developer, you always want to download the latest code, and
> that comes from *develop branch
> * if you want to look at the latest stable release, you look at the
> release branch as per CS git workflow implementation we never remove the
> release branches (they are needed for maintenance releases)
>
>
> It would be great if anyone can point the advantages of #2 approach over
> #1, as to me #1 seems to be the approach most people will find more
> intuitive and its used a lot in the field.
>
> -Alena.
>
>
>
> On 8/5/14, 1:22 PM, "Rayees Namathponnan" <ra...@citrix.com>
> wrote:
>
> >How frequent we can planning to merge from develop to master ?  during
> >release ?
> >
> >Regards,
> >Rayees
> >
> >
> >-----Original Message-----
> >From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
> >Sent: Tuesday, August 05, 2014 11:51 AM
> >To: dev@cloudstack.apache.org
> >Subject: RE: [VOTE] git workflow
> >
> >Sorry if this is already discussed, but few areas that are unclear to me
> >with this process are:
> >
> >- does every fix, however minor it be(say a signle line), needs to be
> >developed in a separate branch? And then we have to merge these
> >individual branches to develop for every fix?
> >- In that case will direct check-ins to 'develop' branch be not allowed?
> >- If not, if CI fails on develop branch, how will one know what caused
> >the failure? Was it some direct checkin Vs some feature/fix merged? Will
> >we revert all the small feature/fixes that were merged to develop branch
> >upto the CI baseline? If yes, wont the developers that did not cause the
> >break get penalized unnecessary?
> >
> >- Lastly, why can't this process be implemented on master? Why are we
> >introducing another branch for the same purposes which the master branch
> >usually serves?
> >
> >
> >I am -1 on this.  We should not start implementing this until all
> >processes are clear.
> >
> >Prachi
> >
> >-----Original Message-----
> >From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
> >Sent: Tuesday, August 05, 2014 11:33 AM
> >To: dev@cloudstack.apache.org
> >Subject: RE: [VOTE] git workflow
> >
> >Exactly. This just shifts pain from one branch to another.
> >I don't see any gains from this, either.
> >I vote "-1".
> >
> >Jessica
> >
> >
> >-----Original Message-----
> >From: Min Chen [mailto:min.chen@citrix.com]
> >Sent: Tuesday, August 05, 2014 11:27 AM
> >To: dev@cloudstack.apache.org
> >Subject: Re: [VOTE] git workflow
> >
> >Agree with Animesh. Didn't see any gains from this, we just shift pain
> >from one branch to another, so vote -1.
> >
> >-min
> >
> >On 8/2/14 9:50 PM, "Animesh Chaturvedi" <an...@citrix.com>
> >wrote:
> >
> >>+0
> >>
> >>While this protects master with only commits which are merges from
> >>release branch and keeps it clean but the issues that we have shift to
> >>develop branch.
> >>
> >>
> >>> -----Original Message-----
> >>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
> >>> Sent: Thursday, July 31, 2014 3:28 AM
> >>> To: dev
> >>> Subject: [VOTE] git workflow
> >>>
> >>> Hi All,
> >>>
> >>> We had long discussions on the git flow.
> >>> I tried to capture the summary of it @
> >>> http://markmail.org/message/j5z7dxjcqxfkfhpj
> >>> This is updated on wiki @
> >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
> >>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
> >>>
> >>> Can you share your opinion on the proposal?
> >>>
> >>> [ ] +1  approve
> >>> [ ] +0  no opinion
> >>> [ ] -1  disapprove (and reason why)
> >>>
> >>>
> >>> Thanks,
> >>> ~Rajani
> >>>
> >>>
> >>
> >
>
>


-- 


*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] git workflow

[Tracy Phillips <tr...@weberize.com>]

"Once you merge release branch it on master/stable branch, you don’t lose
commit if you delete it. It’s like removing a feature branch once it’s
merged on master/target branch."

Correct. At t his point your "release" is in master. If you need to bug
fix, you checkout that tag from master.

Also, as far as CI is concerned it should be ran on the feature branch and
once the feature doesn't break anything, it should only then be merged into
develop.

http://twasink.net/2011/09/20/git-feature-branches-and-jenkins-or-how-i-learned-to-stop-worrying-about-broken-builds/

http://juristr.com/blog/2014/01/git-flow-jenkins-gitlab/

The idea is that you are not pushing a broken feature into a branch.




On Wed, Aug 6, 2014 at 10:55 AM, Rohit Yadav <ro...@shapeblue.com>
wrote:

> Hi David,
>
> On 06-Aug-2014, at 4:10 pm, David Nalley <da...@gnsa.us> wrote:
>
> > On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
> >>
> >> Hi,
> >>
> >> Comments in-line;
> >>
> >> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
> >>
> >>> Rayees,
> >>>
> >>> I think you have the same misunderstanding as a lot of other folks
> >>> (including myself) had in the beginning - seeing develop branch as a
> trunk
> >>> branch that gets merged into master on a regular basis after the BVT/CI
> >>> tests pass. So the master branch reflects the develop branch minus
> changes
> >>> that didn¹t pass the tests and weren¹t merged into master -  lets
> refer to
> >>> it as implementation #1
> >>>
> >>> That¹s not what git workflow/this thread proposes. In git workflow
> master
> >>> branch reflects the latest stable release instead. So for example, we
> >>> released 4.4, and that what you would see the master to be as we merge
> the
> >>> *release branch to master, not the *develop to master. And develop
> branch
> >>> becomes the trunk branch where all the new fixes go to. I would look at
> >>> the master as at the stable branch, where you can track the history for
> >>> all the major releases as for each of them the master branch has
> >>> corresponding tags - lets call it implementation #2
> >>>
> >>> I still don¹t see many advantages in implementation #2 - making the
> master
> >>> build stable by simply making it reflect the latest release branch.
> >>> Because you:
> >>>
> >>> * never cut the release from master branch
> >>
> >> We’ve a stable branch that gets rolling/continuous releases which is
> good.
> >>
> >>> * if you are the customer, and need the latest stable code, you
> download
> >>> the official RPM
> >>> * if you are a developer, you always want to download the latest code,
> and
> >>> that comes from *develop branch
> >>> * if you want to look at the latest stable release, you look at the
> >>> release branch as per CS git workflow implementation we never remove
> the
> >>> release branches (they are needed for maintenance releases)
> >>
> >> IMO We “should" remove the release branches when done. Instead there is
> a support workflow with git-flow (see support
> http://yakiloo.com/getting-started-git-flow/) and also in the tooling
> (git flow support etc. though experimental).
> >>
> >
> > You aren't aiding your case by suggesting that we use experimental
> tooling.
>
> No, if you know you git-chops you can do it by hand, I mean to say -- the
> tool is under development for support stuff.
>
> > So removing a release branch worries me. Will there be loss of commit
> > information?
>
> Once you merge release branch it on master/stable branch, you don’t lose
> commit if you delete it. It’s like removing a feature branch once it’s
> merged on master/target branch.
>
> > I know that heretofore, each release has contained
> > commits that aren't in master. Whether that's good, bad or
> > indifferent, that is the fact, and I personally think that is unlikely
> > to change in the short term.
>
> Once merged on master/stable branch, one can checkout the release version
> tag to get the same branch.
>
> > Or put more succinctly, what does removing a release branch buy us?
>
> Less cluttered branches. You’ve the release branch merged on master and
> tags why do you want to keep branches? You can always checkout the tags to
> get the release branch.
>
> > So I like most of the things about this proposal - I like doing all
> > the work in the feature/bug branches. But the rest of this workflow
> > befuddles me a bit. I don't think that the workflow will result in a
> > stable 'master' or that we are really doing anything significant by
> > pushing what is master now to become the develop branch.
>
> You’re right. It’s just a convention of doing things, like we’ve traffic
> rules.
> They won’t stop you to break anything if you don’t follow.
>
> > In the page
> > describing this, pushes to the develop branch seem welcome 'when a
> > feature is completed' - so develop will be as messy as master is
> > today, frequently broken, and no improvement in quality. This attempts
> > to solve a quality problem with workflow, and I don't think it can do
> > that. Instead, we end up with develop being cluttered and as messy as
> > current master, and we spend time trying to get merge commits from
> > develop -> master and hoping things don't diverge so far in our
> > release branches that we can merge fixes from develop -> master ->
> > release-branches.
>
> I’m not here to "defend git-flow", I like it just because IMO it's better
> than status quo.
>
> We have several threads on this issue now, it adds divergence to the topic
> in the community just like length/divergence/state/stability between
> release branches and master which need to be fixed, so we need some sort of
> protocol/convention that we all agree to. That’s all :)
>
> Let me list out the things I want with our workflow(s) (adaptation from
> git-flow and other places etc.; skipping posting video)
>
> - Baseline protocol, continuous flow of changes and respect for the “tofu
> scale": More -- http://markmail.org/message/4hk2jwvxt4lcpqig
> - Shorter release cycles, less divergent branches (release and master)
> - Make it less painful for RMs and other participants during release, by
> deciding on a sync rule — sync from release branches to master; bug fixes
> go on release branch first, not master
> - Automation in testing (we've CI and WIP efforts)
> - Contributors test their code, don’t break stuff, participate in release
> process. The 4.4.0 IMHO was the worst, low community participation,
> QA/testing
> - You work on ACS first, use it as upstream — you work on ACS and let
> changes trickle down to your distribution, not the reverse direction
> - Influence committers improve their git skills and have ethics when
> working together in the community, follow conventions, push short
> revert-able commits, add design docs and on wiki
> - Convention of branches: prefix namespaces -- “bugfix/“ for bugfixes,
> “support/“ for LTS releases, “release/“ etc.
> - Rolling releases (or shorter release cycles) on support branches for LTS
>
>
> > This is a bit of a change from what we are doing now; why are we doing
> > it? A stable master? I am not sure how a workflow change enforces a
> > stable master. Improved quality? A workflow change might be a part of
> > the solution, but there seems to be missing something that enforces
> > quality or gates on working functionality.
>
> If there is any way I can help, I would prefer a discussion either on IRC
> or on Hangout/Skype/GTM instead of contributing to the length of these
> thread anymore.
>
>
> 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] git workflow

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

Hi David,

On 06-Aug-2014, at 4:10 pm, David Nalley <da...@gnsa.us> wrote:

> On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>
>> Hi,
>>
>> Comments in-line;
>>
>> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk <Al...@citrix.com> wrote:
>>
>>> Rayees,
>>>
>>> I think you have the same misunderstanding as a lot of other folks
>>> (including myself) had in the beginning - seeing develop branch as a trunk
>>> branch that gets merged into master on a regular basis after the BVT/CI
>>> tests pass. So the master branch reflects the develop branch minus changes
>>> that didn¹t pass the tests and weren¹t merged into master -  lets refer to
>>> it as implementation #1
>>>
>>> That¹s not what git workflow/this thread proposes. In git workflow master
>>> branch reflects the latest stable release instead. So for example, we
>>> released 4.4, and that what you would see the master to be as we merge the
>>> *release branch to master, not the *develop to master. And develop branch
>>> becomes the trunk branch where all the new fixes go to. I would look at
>>> the master as at the stable branch, where you can track the history for
>>> all the major releases as for each of them the master branch has
>>> corresponding tags - lets call it implementation #2
>>>
>>> I still don¹t see many advantages in implementation #2 - making the master
>>> build stable by simply making it reflect the latest release branch.
>>> Because you:
>>>
>>> * never cut the release from master branch
>>
>> We’ve a stable branch that gets rolling/continuous releases which is good.
>>
>>> * if you are the customer, and need the latest stable code, you download
>>> the official RPM
>>> * if you are a developer, you always want to download the latest code, and
>>> that comes from *develop branch
>>> * if you want to look at the latest stable release, you look at the
>>> release branch as per CS git workflow implementation we never remove the
>>> release branches (they are needed for maintenance releases)
>>
>> IMO We “should" remove the release branches when done. Instead there is a support workflow with git-flow (see support http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git flow support etc. though experimental).
>>
>
> You aren't aiding your case by suggesting that we use experimental tooling.

No, if you know you git-chops you can do it by hand, I mean to say -- the tool is under development for support stuff.

> So removing a release branch worries me. Will there be loss of commit
> information?

Once you merge release branch it on master/stable branch, you don’t lose commit if you delete it. It’s like removing a feature branch once it’s merged on master/target branch.

> I know that heretofore, each release has contained
> commits that aren't in master. Whether that's good, bad or
> indifferent, that is the fact, and I personally think that is unlikely
> to change in the short term.

Once merged on master/stable branch, one can checkout the release version tag to get the same branch.

> Or put more succinctly, what does removing a release branch buy us?

Less cluttered branches. You’ve the release branch merged on master and tags why do you want to keep branches? You can always checkout the tags to get the release branch.

> So I like most of the things about this proposal - I like doing all
> the work in the feature/bug branches. But the rest of this workflow
> befuddles me a bit. I don't think that the workflow will result in a
> stable 'master' or that we are really doing anything significant by
> pushing what is master now to become the develop branch.

You’re right. It’s just a convention of doing things, like we’ve traffic rules.
They won’t stop you to break anything if you don’t follow.

> In the page
> describing this, pushes to the develop branch seem welcome 'when a
> feature is completed' - so develop will be as messy as master is
> today, frequently broken, and no improvement in quality. This attempts
> to solve a quality problem with workflow, and I don't think it can do
> that. Instead, we end up with develop being cluttered and as messy as
> current master, and we spend time trying to get merge commits from
> develop -> master and hoping things don't diverge so far in our
> release branches that we can merge fixes from develop -> master ->
> release-branches.

I’m not here to "defend git-flow", I like it just because IMO it's better than status quo.

We have several threads on this issue now, it adds divergence to the topic in the community just like length/divergence/state/stability between release branches and master which need to be fixed, so we need some sort of protocol/convention that we all agree to. That’s all :)

Let me list out the things I want with our workflow(s) (adaptation from git-flow and other places etc.; skipping posting video)

- Baseline protocol, continuous flow of changes and respect for the “tofu scale": More -- http://markmail.org/message/4hk2jwvxt4lcpqig
- Shorter release cycles, less divergent branches (release and master)
- Make it less painful for RMs and other participants during release, by deciding on a sync rule — sync from release branches to master; bug fixes go on release branch first, not master
- Automation in testing (we've CI and WIP efforts)
- Contributors test their code, don’t break stuff, participate in release process. The 4.4.0 IMHO was the worst, low community participation, QA/testing
- You work on ACS first, use it as upstream — you work on ACS and let changes trickle down to your distribution, not the reverse direction
- Influence committers improve their git skills and have ethics when working together in the community, follow conventions, push short revert-able commits, add design docs and on wiki
- Convention of branches: prefix namespaces -- “bugfix/“ for bugfixes, “support/“ for LTS releases, “release/“ etc.
- Rolling releases (or shorter release cycles) on support branches for LTS


> This is a bit of a change from what we are doing now; why are we doing
> it? A stable master? I am not sure how a workflow change enforces a
> stable master. Improved quality? A workflow change might be a part of
> the solution, but there seems to be missing something that enforces
> quality or gates on working functionality.

If there is any way I can help, I would prefer a discussion either on IRC or on Hangout/Skype/GTM instead of contributing to the length of these thread anymore.


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] git workflow

[David Nalley <da...@gnsa.us>]

On Wed, Aug 6, 2014 at 10:53 AM, Hugo Trippaers <hu...@trippaers.nl> wrote:
> To me this pretty much ties in to the discussion about the simulator and the BVT/CI suite. This works very neatly with the work Alex has been doing and his proposal on how to deal with the BVT test suite.
>
> His original proposal was about constantly checking master and reverting any commits that would cause master to break.

IIRC his proposal was to gate commits entering master or a release
branch based on them passing BVT/CI. E.g. you had to prove it worked
before it was allowed in. Given our velocity, and the amount of time
that it takes for a CI run there really isn't much choice.

 If we would adopt another branching model like git flow we can change
this around to, merge only when all checks are green. Given an
community that cares about the quality of the software that they are
releasing it will help having a more stable develop/master branch.
>

This makes sense to me. Adopting git flow (or some other workflow) to
keep work out of master/develop until proven that it passes CI - the
workflow change itself, alone does not.

> The big idea is that we get small chunks that we can test individually from each other and once verified merge them into the various branches where we need them. Master would be a special case where only the release manager merges the individual branches that are going to be part of a release. If i got everything correctly (which i doubt, so please correct me).
>
> X develops feature F1
> Y develops feature F2
> Z develops bugfix B1
>
> They are all tested individually and after green light merged into develop, so developers can work with the latest greatest.
>
> On release time we can all decide to take F1 and B1 into the release because they are release grade, so they get merged into master. At all times we can track what is where because of the merging the git commit ids will be the same so a simple check on which branches contain a commit id will tell you where a certain feature or bug fix is included.
>
>
> It requires discipline and a trustworthily CI system, but with those things in place it’s pretty sweet. We run other projects with a similar branching scheme and it works really well. It’s worth to keep pointing out that this is not a standalone thing, it should be regarded with the context of a CI system (or committers doing reviews) that can actually tell us if CloudStack works .
>
>
> Cheers,
>
> Hugo
>
>
> On 6 aug. 2014, at 16:10, David Nalley <da...@gnsa.us> wrote:
>
>> On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>>
>>> Hi,
>>>
>>> Comments in-line;
>>>
>>> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk <Al...@citrix.com> wrote:
>>>
>>>> Rayees,
>>>>
>>>> I think you have the same misunderstanding as a lot of other folks
>>>> (including myself) had in the beginning - seeing develop branch as a trunk
>>>> branch that gets merged into master on a regular basis after the BVT/CI
>>>> tests pass. So the master branch reflects the develop branch minus changes
>>>> that didn¹t pass the tests and weren¹t merged into master -  lets refer to
>>>> it as implementation #1
>>>>
>>>> That¹s not what git workflow/this thread proposes. In git workflow master
>>>> branch reflects the latest stable release instead. So for example, we
>>>> released 4.4, and that what you would see the master to be as we merge the
>>>> *release branch to master, not the *develop to master. And develop branch
>>>> becomes the trunk branch where all the new fixes go to. I would look at
>>>> the master as at the stable branch, where you can track the history for
>>>> all the major releases as for each of them the master branch has
>>>> corresponding tags - lets call it implementation #2
>>>>
>>>> I still don¹t see many advantages in implementation #2 - making the master
>>>> build stable by simply making it reflect the latest release branch.
>>>> Because you:
>>>>
>>>> * never cut the release from master branch
>>>
>>> We’ve a stable branch that gets rolling/continuous releases which is good.
>>>
>>>> * if you are the customer, and need the latest stable code, you download
>>>> the official RPM
>>>> * if you are a developer, you always want to download the latest code, and
>>>> that comes from *develop branch
>>>> * if you want to look at the latest stable release, you look at the
>>>> release branch as per CS git workflow implementation we never remove the
>>>> release branches (they are needed for maintenance releases)
>>>
>>> IMO We “should" remove the release branches when done. Instead there is a support workflow with git-flow (see support http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git flow support etc. though experimental).
>>>
>>
>> You aren't aiding your case by suggesting that we use experimental tooling.
>>
>> So removing a release branch worries me. Will there be loss of commit
>> information? I know that heretofore, each release has contained
>> commits that aren't in master. Whether that's good, bad or
>> indifferent, that is the fact, and I personally think that is unlikely
>> to change in the short term.
>>
>> Or put more succinctly, what does removing a release branch buy us?
>>
>> So I like most of the things about this proposal - I like doing all
>> the work in the feature/bug branches. But the rest of this workflow
>> befuddles me a bit. I don't think that the workflow will result in a
>> stable 'master' or that we are really doing anything significant by
>> pushing what is master now to become the develop branch. In the page
>> describing this, pushes to the develop branch seem welcome 'when a
>> feature is completed' - so develop will be as messy as master is
>> today, frequently broken, and no improvement in quality. This attempts
>> to solve a quality problem with workflow, and I don't think it can do
>> that. Instead, we end up with develop being cluttered and as messy as
>> current master, and we spend time trying to get merge commits from
>> develop -> master and hoping things don't diverge so far in our
>> release branches that we can merge fixes from develop -> master ->
>> release-branches.
>>
>> This is a bit of a change from what we are doing now; why are we doing
>> it? A stable master? I am not sure how a workflow change enforces a
>> stable master. Improved quality? A workflow change might be a part of
>> the solution, but there seems to be missing something that enforces
>> quality or gates on working functionality.
>>
>> --David
>

Re: [VOTE] git workflow

[Hugo Trippaers <hu...@trippaers.nl>]

To me this pretty much ties in to the discussion about the simulator and the BVT/CI suite. This works very neatly with the work Alex has been doing and his proposal on how to deal with the BVT test suite.

His original proposal was about constantly checking master and reverting any commits that would cause master to break. If we would adopt another branching model like git flow we can change this around to, merge only when all checks are green. Given an community that cares about the quality of the software that they are releasing it will help having a more stable develop/master branch.

The big idea is that we get small chunks that we can test individually from each other and once verified merge them into the various branches where we need them. Master would be a special case where only the release manager merges the individual branches that are going to be part of a release. If i got everything correctly (which i doubt, so please correct me).

X develops feature F1
Y develops feature F2
Z develops bugfix B1

They are all tested individually and after green light merged into develop, so developers can work with the latest greatest.

On release time we can all decide to take F1 and B1 into the release because they are release grade, so they get merged into master. At all times we can track what is where because of the merging the git commit ids will be the same so a simple check on which branches contain a commit id will tell you where a certain feature or bug fix is included.


It requires discipline and a trustworthily CI system, but with those things in place it’s pretty sweet. We run other projects with a similar branching scheme and it works really well. It’s worth to keep pointing out that this is not a standalone thing, it should be regarded with the context of a CI system (or committers doing reviews) that can actually tell us if CloudStack works .


Cheers,

Hugo


On 6 aug. 2014, at 16:10, David Nalley <da...@gnsa.us> wrote:

> On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
>> 
>> Hi,
>> 
>> Comments in-line;
>> 
>> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk <Al...@citrix.com> wrote:
>> 
>>> Rayees,
>>> 
>>> I think you have the same misunderstanding as a lot of other folks
>>> (including myself) had in the beginning - seeing develop branch as a trunk
>>> branch that gets merged into master on a regular basis after the BVT/CI
>>> tests pass. So the master branch reflects the develop branch minus changes
>>> that didn¹t pass the tests and weren¹t merged into master -  lets refer to
>>> it as implementation #1
>>> 
>>> That¹s not what git workflow/this thread proposes. In git workflow master
>>> branch reflects the latest stable release instead. So for example, we
>>> released 4.4, and that what you would see the master to be as we merge the
>>> *release branch to master, not the *develop to master. And develop branch
>>> becomes the trunk branch where all the new fixes go to. I would look at
>>> the master as at the stable branch, where you can track the history for
>>> all the major releases as for each of them the master branch has
>>> corresponding tags - lets call it implementation #2
>>> 
>>> I still don¹t see many advantages in implementation #2 - making the master
>>> build stable by simply making it reflect the latest release branch.
>>> Because you:
>>> 
>>> * never cut the release from master branch
>> 
>> We’ve a stable branch that gets rolling/continuous releases which is good.
>> 
>>> * if you are the customer, and need the latest stable code, you download
>>> the official RPM
>>> * if you are a developer, you always want to download the latest code, and
>>> that comes from *develop branch
>>> * if you want to look at the latest stable release, you look at the
>>> release branch as per CS git workflow implementation we never remove the
>>> release branches (they are needed for maintenance releases)
>> 
>> IMO We “should" remove the release branches when done. Instead there is a support workflow with git-flow (see support http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git flow support etc. though experimental).
>> 
> 
> You aren't aiding your case by suggesting that we use experimental tooling.
> 
> So removing a release branch worries me. Will there be loss of commit
> information? I know that heretofore, each release has contained
> commits that aren't in master. Whether that's good, bad or
> indifferent, that is the fact, and I personally think that is unlikely
> to change in the short term.
> 
> Or put more succinctly, what does removing a release branch buy us?
> 
> So I like most of the things about this proposal - I like doing all
> the work in the feature/bug branches. But the rest of this workflow
> befuddles me a bit. I don't think that the workflow will result in a
> stable 'master' or that we are really doing anything significant by
> pushing what is master now to become the develop branch. In the page
> describing this, pushes to the develop branch seem welcome 'when a
> feature is completed' - so develop will be as messy as master is
> today, frequently broken, and no improvement in quality. This attempts
> to solve a quality problem with workflow, and I don't think it can do
> that. Instead, we end up with develop being cluttered and as messy as
> current master, and we spend time trying to get merge commits from
> develop -> master and hoping things don't diverge so far in our
> release branches that we can merge fixes from develop -> master ->
> release-branches.
> 
> This is a bit of a change from what we are doing now; why are we doing
> it? A stable master? I am not sure how a workflow change enforces a
> stable master. Improved quality? A workflow change might be a part of
> the solution, but there seems to be missing something that enforces
> quality or gates on working functionality.
> 
> --David

Re: [VOTE] git workflow

[David Nalley <da...@gnsa.us>]

On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
>
> Hi,
>
> Comments in-line;
>
> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk <Al...@citrix.com> wrote:
>
> > Rayees,
> >
> > I think you have the same misunderstanding as a lot of other folks
> > (including myself) had in the beginning - seeing develop branch as a trunk
> > branch that gets merged into master on a regular basis after the BVT/CI
> > tests pass. So the master branch reflects the develop branch minus changes
> > that didn¹t pass the tests and weren¹t merged into master -  lets refer to
> > it as implementation #1
> >
> > That¹s not what git workflow/this thread proposes. In git workflow master
> > branch reflects the latest stable release instead. So for example, we
> > released 4.4, and that what you would see the master to be as we merge the
> > *release branch to master, not the *develop to master. And develop branch
> > becomes the trunk branch where all the new fixes go to. I would look at
> > the master as at the stable branch, where you can track the history for
> > all the major releases as for each of them the master branch has
> > corresponding tags - lets call it implementation #2
> >
> > I still don¹t see many advantages in implementation #2 - making the master
> > build stable by simply making it reflect the latest release branch.
> > Because you:
> >
> > * never cut the release from master branch
>
> We’ve a stable branch that gets rolling/continuous releases which is good.
>
> > * if you are the customer, and need the latest stable code, you download
> > the official RPM
> > * if you are a developer, you always want to download the latest code, and
> > that comes from *develop branch
> > * if you want to look at the latest stable release, you look at the
> > release branch as per CS git workflow implementation we never remove the
> > release branches (they are needed for maintenance releases)
>
> IMO We “should" remove the release branches when done. Instead there is a support workflow with git-flow (see support http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git flow support etc. though experimental).
>

You aren't aiding your case by suggesting that we use experimental tooling.

So removing a release branch worries me. Will there be loss of commit
information? I know that heretofore, each release has contained
commits that aren't in master. Whether that's good, bad or
indifferent, that is the fact, and I personally think that is unlikely
to change in the short term.

Or put more succinctly, what does removing a release branch buy us?

So I like most of the things about this proposal - I like doing all
the work in the feature/bug branches. But the rest of this workflow
befuddles me a bit. I don't think that the workflow will result in a
stable 'master' or that we are really doing anything significant by
pushing what is master now to become the develop branch. In the page
describing this, pushes to the develop branch seem welcome 'when a
feature is completed' - so develop will be as messy as master is
today, frequently broken, and no improvement in quality. This attempts
to solve a quality problem with workflow, and I don't think it can do
that. Instead, we end up with develop being cluttered and as messy as
current master, and we spend time trying to get merge commits from
develop -> master and hoping things don't diverge so far in our
release branches that we can merge fixes from develop -> master ->
release-branches.

This is a bit of a change from what we are doing now; why are we doing
it? A stable master? I am not sure how a workflow change enforces a
stable master. Improved quality? A workflow change might be a part of
the solution, but there seems to be missing something that enforces
quality or gates on working functionality.

--David

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Rohit, addressing the following comment:

"IMO We “should" remove the release branches when done. Instead there is a
support workflow with git-flow (see support
http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git
flow support etc. though experimental).”

If we remove the release branches, how are we going to handle maintenance
releases for older versions of the code? It wouldn’t work as its
impossible to cut a maintenance release from develop branch.

I think the model the article proposes, fits the products like SAS, when
there are no maintenance releases and support is provided just for the
latest release.  Then of course, to get the latest stable release, it
would make sense to access master branch which is always stable. In case
when multiple releases are being maintained at the same time - like CS -
it would make sense to keep release branches. Otherwise how are you going
to handle this situation:

4.2, 4.3 and 4.4 are released
Master reflects 4.4
Maintenance 4.2.1 and 4.3.1 releases are needed

Questions:
How do you create those releases, from what branch?
How do you merge and tag them into master branch considering that the
latest version there is 4.4?

Thanks,
Alena.


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

>Hi,
>
>Comments in-line;
>
>On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk
><Al...@citrix.com> wrote:
>
>> Rayees,
>>
>> I think you have the same misunderstanding as a lot of other folks
>> (including myself) had in the beginning - seeing develop branch as a
>>trunk
>> branch that gets merged into master on a regular basis after the BVT/CI
>> tests pass. So the master branch reflects the develop branch minus
>>changes
>> that didn¹t pass the tests and weren¹t merged into master -  lets refer
>>to
>> it as implementation #1
>>
>> That¹s not what git workflow/this thread proposes. In git workflow
>>master
>> branch reflects the latest stable release instead. So for example, we
>> released 4.4, and that what you would see the master to be as we merge
>>the
>> *release branch to master, not the *develop to master. And develop
>>branch
>> becomes the trunk branch where all the new fixes go to. I would look at
>> the master as at the stable branch, where you can track the history for
>> all the major releases as for each of them the master branch has
>> corresponding tags - lets call it implementation #2
>>
>> I still don¹t see many advantages in implementation #2 - making the
>>master
>> build stable by simply making it reflect the latest release branch.
>> Because you:
>>
>> * never cut the release from master branch
>
>We’ve a stable branch that gets rolling/continuous releases which is good.
>
>> * if you are the customer, and need the latest stable code, you download
>> the official RPM
>> * if you are a developer, you always want to download the latest code,
>>and
>> that comes from *develop branch
>> * if you want to look at the latest stable release, you look at the
>> release branch as per CS git workflow implementation we never remove the
>> release branches (they are needed for maintenance releases)
>
>IMO We “should" remove the release branches when done. Instead there is a
>support workflow with git-flow (see support
>http://yakiloo.com/getting-started-git-flow/) and also in the tooling
>(git flow support etc. though experimental).
>
>I’ll create a video to describe what we can do with this workflow,
>instead of going back and forth on the ML.
>We don’t need to change our workflow, we can learn from this and adapt to
>our workflow.
>
>
>> It would be great if anyone can point the advantages of #2 approach over
>> #1, as to me #1 seems to be the approach most people will find more
>> intuitive and its used a lot in the field.
>>
>> -Alena.
>>
>>
>>
>> On 8/5/14, 1:22 PM, "Rayees Namathponnan"
>><ra...@citrix.com>
>> wrote:
>>
>>> How frequent we can planning to merge from develop to master ?  during
>>> release ?
>>>
>>> Regards,
>>> Rayees
>>>
>>>
>>> -----Original Message-----
>>> From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
>>> Sent: Tuesday, August 05, 2014 11:51 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: RE: [VOTE] git workflow
>>>
>>> Sorry if this is already discussed, but few areas that are unclear to
>>>me
>>> with this process are:
>>>
>>> - does every fix, however minor it be(say a signle line), needs to be
>>> developed in a separate branch? And then we have to merge these
>>> individual branches to develop for every fix?
>>> - In that case will direct check-ins to 'develop' branch be not
>>>allowed?
>>> - If not, if CI fails on develop branch, how will one know what caused
>>> the failure? Was it some direct checkin Vs some feature/fix merged?
>>>Will
>>> we revert all the small feature/fixes that were merged to develop
>>>branch
>>> upto the CI baseline? If yes, wont the developers that did not cause
>>>the
>>> break get penalized unnecessary?
>>>
>>> - Lastly, why can't this process be implemented on master? Why are we
>>> introducing another branch for the same purposes which the master
>>>branch
>>> usually serves?
>>>
>>>
>>> I am -1 on this.  We should not start implementing this until all
>>> processes are clear.
>>>
>>> Prachi
>>>
>>> -----Original Message-----
>>> From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
>>> Sent: Tuesday, August 05, 2014 11:33 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: RE: [VOTE] git workflow
>>>
>>> Exactly. This just shifts pain from one branch to another.
>>> I don't see any gains from this, either.
>>> I vote "-1".
>>>
>>> Jessica
>>>
>>>
>>> -----Original Message-----
>>> From: Min Chen [mailto:min.chen@citrix.com]
>>> Sent: Tuesday, August 05, 2014 11:27 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [VOTE] git workflow
>>>
>>> Agree with Animesh. Didn't see any gains from this, we just shift pain
>>> from one branch to another, so vote -1.
>>>
>>> -min
>>>
>>> On 8/2/14 9:50 PM, "Animesh Chaturvedi" <an...@citrix.com>
>>> wrote:
>>>
>>>> +0
>>>>
>>>> While this protects master with only commits which are merges from
>>>> release branch and keeps it clean but the issues that we have shift to
>>>> develop branch.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>>>>> Sent: Thursday, July 31, 2014 3:28 AM
>>>>> To: dev
>>>>> Subject: [VOTE] git workflow
>>>>>
>>>>> Hi All,
>>>>>
>>>>> We had long discussions on the git flow.
>>>>> I tried to capture the summary of it @
>>>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>>>> This is updated on wiki @
>>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>>>>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>>>>>
>>>>> Can you share your opinion on the proposal?
>>>>>
>>>>> [ ] +1  approve
>>>>> [ ] +0  no opinion
>>>>> [ ] -1  disapprove (and reason why)
>>>>>
>>>>>
>>>>> Thanks,
>>>>> ~Rajani
>>>>>
>>>>>
>>>>
>>>
>>
>
>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] git workflow

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

Hi,

Comments in-line;

On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk <Al...@citrix.com> wrote:

> Rayees,
>
> I think you have the same misunderstanding as a lot of other folks
> (including myself) had in the beginning - seeing develop branch as a trunk
> branch that gets merged into master on a regular basis after the BVT/CI
> tests pass. So the master branch reflects the develop branch minus changes
> that didn¹t pass the tests and weren¹t merged into master -  lets refer to
> it as implementation #1
>
> That¹s not what git workflow/this thread proposes. In git workflow master
> branch reflects the latest stable release instead. So for example, we
> released 4.4, and that what you would see the master to be as we merge the
> *release branch to master, not the *develop to master. And develop branch
> becomes the trunk branch where all the new fixes go to. I would look at
> the master as at the stable branch, where you can track the history for
> all the major releases as for each of them the master branch has
> corresponding tags - lets call it implementation #2
>
> I still don¹t see many advantages in implementation #2 - making the master
> build stable by simply making it reflect the latest release branch.
> Because you:
>
> * never cut the release from master branch

We’ve a stable branch that gets rolling/continuous releases which is good.

> * if you are the customer, and need the latest stable code, you download
> the official RPM
> * if you are a developer, you always want to download the latest code, and
> that comes from *develop branch
> * if you want to look at the latest stable release, you look at the
> release branch as per CS git workflow implementation we never remove the
> release branches (they are needed for maintenance releases)

IMO We “should" remove the release branches when done. Instead there is a support workflow with git-flow (see support http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git flow support etc. though experimental).

I’ll create a video to describe what we can do with this workflow, instead of going back and forth on the ML.
We don’t need to change our workflow, we can learn from this and adapt to our workflow.


> It would be great if anyone can point the advantages of #2 approach over
> #1, as to me #1 seems to be the approach most people will find more
> intuitive and its used a lot in the field.
>
> -Alena.
>
>
>
> On 8/5/14, 1:22 PM, "Rayees Namathponnan" <ra...@citrix.com>
> wrote:
>
>> How frequent we can planning to merge from develop to master ?  during
>> release ?
>>
>> Regards,
>> Rayees
>>
>>
>> -----Original Message-----
>> From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
>> Sent: Tuesday, August 05, 2014 11:51 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [VOTE] git workflow
>>
>> Sorry if this is already discussed, but few areas that are unclear to me
>> with this process are:
>>
>> - does every fix, however minor it be(say a signle line), needs to be
>> developed in a separate branch? And then we have to merge these
>> individual branches to develop for every fix?
>> - In that case will direct check-ins to 'develop' branch be not allowed?
>> - If not, if CI fails on develop branch, how will one know what caused
>> the failure? Was it some direct checkin Vs some feature/fix merged? Will
>> we revert all the small feature/fixes that were merged to develop branch
>> upto the CI baseline? If yes, wont the developers that did not cause the
>> break get penalized unnecessary?
>>
>> - Lastly, why can't this process be implemented on master? Why are we
>> introducing another branch for the same purposes which the master branch
>> usually serves?
>>
>>
>> I am -1 on this.  We should not start implementing this until all
>> processes are clear.
>>
>> Prachi
>>
>> -----Original Message-----
>> From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
>> Sent: Tuesday, August 05, 2014 11:33 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [VOTE] git workflow
>>
>> Exactly. This just shifts pain from one branch to another.
>> I don't see any gains from this, either.
>> I vote "-1".
>>
>> Jessica
>>
>>
>> -----Original Message-----
>> From: Min Chen [mailto:min.chen@citrix.com]
>> Sent: Tuesday, August 05, 2014 11:27 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] git workflow
>>
>> Agree with Animesh. Didn't see any gains from this, we just shift pain
>> from one branch to another, so vote -1.
>>
>> -min
>>
>> On 8/2/14 9:50 PM, "Animesh Chaturvedi" <an...@citrix.com>
>> wrote:
>>
>>> +0
>>>
>>> While this protects master with only commits which are merges from
>>> release branch and keeps it clean but the issues that we have shift to
>>> develop branch.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>>>> Sent: Thursday, July 31, 2014 3:28 AM
>>>> To: dev
>>>> Subject: [VOTE] git workflow
>>>>
>>>> Hi All,
>>>>
>>>> We had long discussions on the git flow.
>>>> I tried to capture the summary of it @
>>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>>> This is updated on wiki @
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>>>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>>>>
>>>> Can you share your opinion on the proposal?
>>>>
>>>> [ ] +1  approve
>>>> [ ] +0  no opinion
>>>> [ ] -1  disapprove (and reason why)
>>>>
>>>>
>>>> Thanks,
>>>> ~Rajani
>>>>
>>>>
>>>
>>
>

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] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Rayees, 

I think you have the same misunderstanding as a lot of other folks
(including myself) had in the beginning - seeing develop branch as a trunk
branch that gets merged into master on a regular basis after the BVT/CI
tests pass. So the master branch reflects the develop branch minus changes
that didn¹t pass the tests and weren¹t merged into master -  lets refer to
it as implementation #1

That¹s not what git workflow/this thread proposes. In git workflow master
branch reflects the latest stable release instead. So for example, we
released 4.4, and that what you would see the master to be as we merge the
*release branch to master, not the *develop to master. And develop branch
becomes the trunk branch where all the new fixes go to. I would look at
the master as at the stable branch, where you can track the history for
all the major releases as for each of them the master branch has
corresponding tags - lets call it implementation #2

I still don¹t see many advantages in implementation #2 - making the master
build stable by simply making it reflect the latest release branch.
Because you:

* never cut the release from master branch
* if you are the customer, and need the latest stable code, you download
the official RPM
* if you are a developer, you always want to download the latest code, and
that comes from *develop branch
* if you want to look at the latest stable release, you look at the
release branch as per CS git workflow implementation we never remove the
release branches (they are needed for maintenance releases)


It would be great if anyone can point the advantages of #2 approach over
#1, as to me #1 seems to be the approach most people will find more
intuitive and its used a lot in the field.

-Alena.



On 8/5/14, 1:22 PM, "Rayees Namathponnan" <ra...@citrix.com>
wrote:

>How frequent we can planning to merge from develop to master ?  during
>release ?   
>
>Regards,
>Rayees 
>
>
>-----Original Message-----
>From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
>Sent: Tuesday, August 05, 2014 11:51 AM
>To: dev@cloudstack.apache.org
>Subject: RE: [VOTE] git workflow
>
>Sorry if this is already discussed, but few areas that are unclear to me
>with this process are:
>
>- does every fix, however minor it be(say a signle line), needs to be
>developed in a separate branch? And then we have to merge these
>individual branches to develop for every fix?
>- In that case will direct check-ins to 'develop' branch be not allowed?
>- If not, if CI fails on develop branch, how will one know what caused
>the failure? Was it some direct checkin Vs some feature/fix merged? Will
>we revert all the small feature/fixes that were merged to develop branch
>upto the CI baseline? If yes, wont the developers that did not cause the
>break get penalized unnecessary?
>
>- Lastly, why can't this process be implemented on master? Why are we
>introducing another branch for the same purposes which the master branch
>usually serves?
>
>
>I am -1 on this.  We should not start implementing this until all
>processes are clear.
>
>Prachi
>
>-----Original Message-----
>From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
>Sent: Tuesday, August 05, 2014 11:33 AM
>To: dev@cloudstack.apache.org
>Subject: RE: [VOTE] git workflow
>
>Exactly. This just shifts pain from one branch to another.
>I don't see any gains from this, either.
>I vote "-1".
>
>Jessica
>
>
>-----Original Message-----
>From: Min Chen [mailto:min.chen@citrix.com]
>Sent: Tuesday, August 05, 2014 11:27 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [VOTE] git workflow
>
>Agree with Animesh. Didn't see any gains from this, we just shift pain
>from one branch to another, so vote -1.
>
>-min
>
>On 8/2/14 9:50 PM, "Animesh Chaturvedi" <an...@citrix.com>
>wrote:
>
>>+0
>>
>>While this protects master with only commits which are merges from
>>release branch and keeps it clean but the issues that we have shift to
>>develop branch.
>>
>>
>>> -----Original Message-----
>>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>>> Sent: Thursday, July 31, 2014 3:28 AM
>>> To: dev
>>> Subject: [VOTE] git workflow
>>> 
>>> Hi All,
>>> 
>>> We had long discussions on the git flow.
>>> I tried to capture the summary of it @
>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>> This is updated on wiki @
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>>> 
>>> Can you share your opinion on the proposal?
>>> 
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>> 
>>> 
>>> Thanks,
>>> ~Rajani
>>> 
>>> 
>>
>

RE: [VOTE] git workflow

[Rayees Namathponnan <ra...@citrix.com>]

How frequent we can planning to merge from develop to master ?  during release ?   

Regards,
Rayees 


-----Original Message-----
From: Prachi Damle [mailto:Prachi.Damle@citrix.com] 
Sent: Tuesday, August 05, 2014 11:51 AM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] git workflow

Sorry if this is already discussed, but few areas that are unclear to me with this process are:

- does every fix, however minor it be(say a signle line), needs to be developed in a separate branch? And then we have to merge these individual branches to develop for every fix?
- In that case will direct check-ins to 'develop' branch be not allowed?
- If not, if CI fails on develop branch, how will one know what caused the failure? Was it some direct checkin Vs some feature/fix merged? Will we revert all the small feature/fixes that were merged to develop branch upto the CI baseline? If yes, wont the developers that did not cause the break get penalized unnecessary?

- Lastly, why can't this process be implemented on master? Why are we introducing another branch for the same purposes which the master branch usually serves?


I am -1 on this.  We should not start implementing this until all processes are clear.

Prachi

-----Original Message-----
From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
Sent: Tuesday, August 05, 2014 11:33 AM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] git workflow

Exactly. This just shifts pain from one branch to another. 
I don't see any gains from this, either.
I vote "-1".

Jessica


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

Agree with Animesh. Didn't see any gains from this, we just shift pain from one branch to another, so vote -1.

-min

On 8/2/14 9:50 PM, "Animesh Chaturvedi" <an...@citrix.com>
wrote:

>+0
>
>While this protects master with only commits which are merges from 
>release branch and keeps it clean but the issues that we have shift to 
>develop branch.
>
>
>> -----Original Message-----
>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>> Sent: Thursday, July 31, 2014 3:28 AM
>> To: dev
>> Subject: [VOTE] git workflow
>> 
>> Hi All,
>> 
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @ 
>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>> 
>> Can you share your opinion on the proposal?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> 
>> Thanks,
>> ~Rajani
>> 
>> 
>

Re: [VOTE] git workflow

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

Hi,

Sorry to see -1s, I was skeptic too and explored every bit of the workflow and usage of git and I think it’s a good model.

TL;DR? I hear you and the wiki is changing a lot, so just go through the cheatsheet and come back to this email:
http://danielkummer.github.io/git-flow-cheatsheet

If you need a quick intro, see this 6 min video: https://www.youtube.com/watch?v=I-73cssiVC4

If you have time, go through these entire 30+ mins videos:

Using git-flow to releave your headaches: https://www.youtube.com/watch?v=NdXhz4rt_sQ
What is git-flow: https://www.youtube.com/watch?v=T-miCpHxfds

Or, better install git-flow and play with it on a sample repo:
https://github.com/nvie/gitflow/wiki/Installation
Play with it — http://yakiloo.com/getting-started-git-flow





TL;DR again? I would be happy to have a Hangout/Skype/GTM and whatnot call to explain and discuss why this is better than our current workflow and help you reach a conclusion if it’s for you or not.

There are several gains of this model, some of them I’ll list below:

- A tried and tested convention for over 4 years, so it would take new folks less time to learn the convention
- The git-flow tooling is great, there are less chances of collateral conflicts and across release branches (since there is a single release branch)
- At any time there are 5 main (type of) branches that you need to understand around which the whole workflow “works"
- A rolling release model/workflow is possible
- It follows a landing rule that you cannot land changes from release to master, i.e. you never cherry-pick, merge, rebase etc. from an unstable branch to a stable/firm branch
- Unlike current release branches, there is a single “released” branch that is master and staging/development branch “develop”. Every release is tagged on master, it would be useful when doing LTS releases
- Ability to have support branches, again useful for LTS kind of releases.
- I think RMs will like it, as they won’t have to chase around branches or development to find what got in and what not and what to sync from where to where: the rule is simple, you cut out release branch from “develop” work on it, test it and stablize it. At the time of release you merge it to “develop” and “master”. On master you tag the release and you “release” ACS. (Merging from “release” to “develop” may cause conflicts so you fix it)

IMHO we can beat any workflow so it can only work if everyone agree and follows the workflow and other good stuff from the Git wiki: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git

Hi Prachi, please find my comments in-line below;

On 05-Aug-2014, at 8:51 pm, Prachi Damle <pr...@citrix.com> wrote:

> Sorry if this is already discussed, but few areas that are unclear to me with this process are:
>
> - does every fix, however minor it be(say a signle line), needs to be developed in a separate branch? And then we have to merge these individual branches to develop for every fix?

Since, it’s hard to know how many commits every bug or feature work may consist of it’s a good idea to start off with a separate branch and sync that branch (back or push) on remote (asf repo or your own github repo);
  - If you want the git history to have history that you worked on a separate branch when you merge you do: git checkout develop && git merge --no-ff <your-work-branch> --no-ff
  - Most of the times you may just want a linear history (say one commit in the branch and you don’t want to create a merge commit), you do: git checkout develop && git merge -ff <your-branch>

For feature work and a regular bugfix during development you should start a “feature/“ branch and work on it as per the default convention. You use the “hotfix/“ branching/merging on master only when there is a serious bug need to be fixed for already released versions and you need to publish (emergency) releases, the heartbleed bug qualifies for that but not your regular bugs.

Shoutout to some folks who have created “hotfix/“ branches, please read above :)

> - In that case will direct check-ins to 'develop' branch be not allowed?

It’s fine to check-in directly to develop. While doing that, please don’t break develop like it’s expected for master (like at present) :)

> - If not, if CI fails on develop branch, how will one know what caused the failure? Was it some direct checkin Vs some feature/fix merged? Will we revert all the small feature/fixes that were merged to develop branch upto the CI baseline? If yes, wont the developers that did not cause the break get penalized unnecessary?

CI/Jenkins will still be needed, this workflow does not guarantee human error causing accidental breakage unlike any other technology. As committers and developers it’s our duty to make sure we either ask the ‘breaker’ to fix it, or revert and politely let them know, or lastly fix ourselves. There is not need to penalise anyone, the reverting part should be done by a human and not a cron job IMHO.

> - Lastly, why can't this process be implemented on master? Why are we introducing another branch for the same purposes which the master branch usually serves?

Well, actually we can. Git-flow allows you to rename the conventional branch. But there is a reason I would want to adopt the convention:
- as git-flow is in-fact widely used and it would be easier for people to just follow the git-flow workflow
- new folks don'tdon’t have to learn git-flow and then learn the ACS project specific changes we did (we already tried changing the maven convention and it was difficult)
- new folks would simply want to checkout master and they would expect it to work

Cheers.

>
>
> I am -1 on this.  We should not start implementing this until all processes are clear.
>
> Prachi
>
> -----Original Message-----
> From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
> Sent: Tuesday, August 05, 2014 11:33 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] git workflow
>
> Exactly. This just shifts pain from one branch to another.
> I don't see any gains from this, either.
> I vote "-1".
>
> Jessica
>
>
> -----Original Message-----
> From: Min Chen [mailto:min.chen@citrix.com]
> Sent: Tuesday, August 05, 2014 11:27 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] git workflow
>
> Agree with Animesh. Didn't see any gains from this, we just shift pain from one branch to another, so vote -1.
>
> -min
>
> On 8/2/14 9:50 PM, "Animesh Chaturvedi" <an...@citrix.com>
> wrote:
>
>> +0
>>
>> While this protects master with only commits which are merges from
>> release branch and keeps it clean but the issues that we have shift to
>> develop branch.
>>
>>
>>> -----Original Message-----
>>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>>> Sent: Thursday, July 31, 2014 3:28 AM
>>> To: dev
>>> Subject: [VOTE] git workflow
>>>
>>> Hi All,
>>>
>>> We had long discussions on the git flow.
>>> I tried to capture the summary of it @
>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>> This is updated on wiki @
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>>>
>>> Can you share your opinion on the proposal?
>>>
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>>
>>>
>>> Thanks,
>>> ~Rajani
>>>
>>>
>>
>

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] git workflow

[Prachi Damle <Pr...@citrix.com>]

Sorry if this is already discussed, but few areas that are unclear to me with this process are:

- does every fix, however minor it be(say a signle line), needs to be developed in a separate branch? And then we have to merge these individual branches to develop for every fix?
- In that case will direct check-ins to 'develop' branch be not allowed?
- If not, if CI fails on develop branch, how will one know what caused the failure? Was it some direct checkin Vs some feature/fix merged? Will we revert all the small feature/fixes that were merged to develop branch upto the CI baseline? If yes, wont the developers that did not cause the break get penalized unnecessary?

- Lastly, why can't this process be implemented on master? Why are we introducing another branch for the same purposes which the master branch usually serves?


I am -1 on this.  We should not start implementing this until all processes are clear.

Prachi

-----Original Message-----
From: Jessica Wang [mailto:Jessica.Wang@citrix.com] 
Sent: Tuesday, August 05, 2014 11:33 AM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] git workflow

Exactly. This just shifts pain from one branch to another. 
I don't see any gains from this, either.
I vote "-1".

Jessica


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

Agree with Animesh. Didn't see any gains from this, we just shift pain from one branch to another, so vote -1.

-min

On 8/2/14 9:50 PM, "Animesh Chaturvedi" <an...@citrix.com>
wrote:

>+0
>
>While this protects master with only commits which are merges from 
>release branch and keeps it clean but the issues that we have shift to 
>develop branch.
>
>
>> -----Original Message-----
>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>> Sent: Thursday, July 31, 2014 3:28 AM
>> To: dev
>> Subject: [VOTE] git workflow
>> 
>> Hi All,
>> 
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @ 
>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>> 
>> Can you share your opinion on the proposal?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> 
>> Thanks,
>> ~Rajani
>> 
>> 
>

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Rohit, whatever you say below, just proves our original worry about
handling the maintenance minor releases (see my comments below). We can’t
possibly adopt the way where release branches get removed since we always
support maintenance releases for multiple versions at a time: 4.2.1,
4.3.1, 4.4.1.

Thanks,
Alena.

On 8/6/14, 11:06 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:

>Hi,
>
>On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk
><Al...@citrix.com> wrote:
>
>> Rohit, thank you for the explanation. So we cut the maintenance release
>> from the master branch, not *develop as opposed to the major release
>> branch.
>>
>> One more open question. Its clear that we cut the maintenance release
>>from
>> the master branch, but what would be the right way to merge it back if
>> this is a maintenance release for say 4.2, and 4.4 is the top of the
>> master branch? Where would the 4.2.1 tag appear? It can’t be on a top of
>> 4.4
>
>You checkout a support branch from 4.2 tag (or for that matter you may
>keep the 4.2 release branch, it’s same) for LTS/support.
>You tag 4.2.1 on the support branch. (it’s the same way you would do like
>we do it now). I think git-flow is suitable for rolling releases and may
>not 100% work with our deployment/release process. One thing I’ve
>suggested is shortening of our release cycles which can help.

The argument - "I’ve suggested is shortening of our release cycles which
can help.” - can’t be taken to consideration as its not implemented. Only
after its implemented, and we agree that we don’t support minor releases,
then we can use it.


>
>The flow of commits/fixes/changes would follow the baseline protocol —
>from firm branch to soft branches chronologically, so if there is a bug
>on 4.2 release you fix it on 4.2 support branch and
>cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch and
>then to 4.4 support branch … to 4.5 release branch to develop branch.


So we do keep the releases branches? :) Which what “support” branch
eventually becomes. You get rid of release branch by merging and tagging
it to master, but eventually you bring it back once its time for minor
maintenance release, but now call it “support”. And if you are cutting
support branch for 4.2.1, you need to merge changes to all the branches on
master! By creating support branches for 4.2, 4.3, 4.4, 4.5. That doesn’t
seem like a valid model to me.



>
>I think git-flow assumes the releases will be chronological so you don’t
>release 4.3.1 after 4.4 etc and you always progress? I’m not sure.
>We can think of better ways of doing things, we can also learn from how
>other projects do it.


That’s what I was afraid of, and already pointed it out that the model the
article suggest, suits only SAAS like models, when there is no support for
minor maintenance releases.


>
>Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be
>painful, that always felt to me like maintaining a whole different
>product. If we can do something about that, we’re going to make a lot of
>people happy IMO.
>
>>
>>
>> All the above should be documented in the proposal. The original
>>proposal
>> didn’t mention anything about how we are going to do maintenance
>>branches.
>> And we were originally thinking about leaving the release branches
>>around.
>>
>> Thanks,
>> Alena.
>>
>>
>> On 8/6/14, 10:16 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>
>>>
>>> On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk
>>> <Al...@citrix.com> wrote:
>>>
>>>> Why implement something that doesn¹t serve any practical purpose for
>>>> CS??
>>>> We should adopt only things that would address current CS problems -
>>>> regressions, unstable releases, etc. That would mean - running the
>>>> automation (CI, BVT) on *develop branch, cut the *fix branches for hot
>>>> fixes/critical/feature bugs only and run BVT on them before merging to
>>>> *develop; merge only stable code from *develop to master branch.
>>>>
>>>> There would be no use for master branch if it reflects the latest
>>>> release
>>>> branch, which will always be present in CS model as opposed to what
>>>> original article suggests. Below the explanation from the other email
>>>> thread on why the release branches can¹t be removed in CS model:
>>>>
>>>> Rohit:
>>>> ================
>>>>
>>>> "IMO We ³should" remove the release branches when done. Instead there
>>>> is a
>>>> support workflow with git-flow (see support
>>>> http://yakiloo.com/getting-started-git-flow/) and also in the tooling
>>>> (git
>>>> flow support etc. though experimental).²
>>>>
>>>> Alena:
>>>> ==========
>>>> If we remove the release branches, how are we going to handle
>>>> maintenance
>>>> releases for older versions of the code? It wouldn¹t work as its
>>>> impossible to cut a maintenance release from develop branch.
>>>
>>> When you merge --no-ff a release/any branch on master/target branch,
>>>the
>>> version history stays with it.
>>> Not only we merge it on master, we do a tag on it as well. Now to get
>>>the
>>> history/branch back you can always checkout the tag: git checkout <tag>
>>> and see the history:
>>> git log --graph --decorate --pretty=oneline --abbrev-commit —all
>>>
>>> So, it’s safe to delete a branch when it’s merged to a target/master
>>> branch.
>>> If you have never deleted a feature branch once it was merged, you
>>>should
>>> try and see for yourself. At the end of the day, git is all but
>>>link-list
>>> logic at the core. The branch too tracks just the HEAD, if you’ve
>>> refs/tag/sha of a branch you can checkout to get the branch back.
>>>
>>> When a branch is merged, git allows you do delete the branch with: git
>>> branch -d <release>, if branch is not merged you’ve to force it with
>>>-D:
>>> git branch -D <release>
>>> To cut a maintenance release from a release version, all you’ll have to
>>> do it:
>>> git checkout -b <support-branch> <tag>
>>>
>>> HTH.
>>>
>>>> I think the model the article proposes, fits the products like SAS,
>>>>when
>>>> there are no maintenance releases and support is provided just for the
>>>> latest release.  Then of course, to get the latest stable release, it
>>>> would make sense to access master branch which is always stable. In
>>>>case
>>>> when multiple releases are being maintained at the same time - like
>>>>CS -
>>>> it would make sense to keep release branches. Otherwise how are you
>>>> going
>>>> to handle this situation:
>>>>
>>>> 4.2, 4.3 and 4.4 are released
>>>> Master reflects 4.4
>>>> Maintenance 4.2.1 and 4.3.1 releases are needed
>>>>
>>>> Questions:
>>>> How do you create those releases, from what branch?
>>>> How do you merge and tag them into master branch considering that the
>>>> latest version there is 4.4?
>>>>
>>>> Thanks,
>>>> Alena.
>>>>
>>>>
>>>>
>>>>
>>>> On 8/5/14, 11:36 PM, "Daan Hoogland" <da...@gmail.com> wrote:
>>>>
>>>>> Exactly Rajani, and other solutions are possible. The issue is not
>>>>>how
>>>>> branches are called ;)
>>>>>
>>>>> On Wed, Aug 6, 2014 at 8:29 AM, Rajani Karuturi
>>>>> <Ra...@citrix.com> wrote:
>>>>>> I am just wondering if the shift to a new develop branch is causing
>>>>>> the
>>>>>> problems. Its a simple branch shift and should be no different from
>>>>>> the
>>>>>> current master.
>>>>>>
>>>>>> may be we should leave the master as is and create a Œstable' branch
>>>>>> which would act like master in git-flow ?
>>>>>>
>>>>>> ie)
>>>>>> ACS master -> develop in git-flow
>>>>>> ACS stable -> master in git-flow
>>>>>>
>>>>>>
>>>>>> ~Rajani
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 06-Aug-2014, at 10:56 am, Daan Hoogland <da...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello devs and especially committters,
>>>>>>>
>>>>>>> I see some -1s coming by, days after the vote was closed. That is
>>>>>>> disturbing as it means we accepted a proposal that will not be
>>>>>>> supported by the community. So let me try to find that support in
>>>>>>> hindsight;
>>>>>>>
>>>>>>> The argument of Animesh that we are shifting the burden from one
>>>>>>> branch to another is real and present danger. I share his concern.
>>>>>>>It
>>>>>>> is not the only feature of this proposal and in it self does not
>>>>>>> warrant a -1. It does not worsen the situation at hand or add to
>>>>>>>our
>>>>>>> workload in any way. If there is no advantage to you and no
>>>>>>> disadvantage either then why -1 something that others do find
>>>>>>>useful?
>>>>>>> This is 'kind of' a rhetorical question. It is a real concern,
>>>>>>> however
>>>>>>> though not the biggest at this moment.
>>>>>>>
>>>>>>> branching is recommended but as people are rightfully wondering
>>>>>>> "should I make a branch for a single line fix". I would, probably
>>>>>>>but
>>>>>>> maybe not always. That doesn't mean you must. In case you are
>>>>>>>making
>>>>>>> a
>>>>>>> fix on a release then yes you do. It is how the git-flow workflow
>>>>>>> goes.
>>>>>>>
>>>>>>> Committers can merge and commit where ever they feel the need. That
>>>>>>> doesn't exempt them from thinking if it is a good idea. It doesn't
>>>>>>> now
>>>>>>> and it won't in the future. Doing what your boss tells you to do
>>>>>>>can
>>>>>>> be a crime!
>>>>>>>
>>>>>>> Reverting something should only be done when the code that is a
>>>>>>> culprit has been identified. Reverting a big change or even a bunch
>>>>>>> of
>>>>>>> changes is a cowards way out. We shouldn't do it now or using
>>>>>>> gitflow.
>>>>>>> It is not really related to git flow or its use. So we shouldn't
>>>>>>> penalize developers that didn't cause a problem or ones that did.
>>>>>>>We
>>>>>>> should help them help us make a better system.
>>>>>>>
>>>>>>> The question of why this process isn't implemented on master is
>>>>>>> valid.
>>>>>>> It could. It isn't however. It is a choice the authors of gitflow
>>>>>>> made. I think it is not really the time anymore to be nitpicking
>>>>>>> about
>>>>>>> this. Unless we find a very valid reason to alter the accepted
>>>>>>> proposal we should all try and implement it as good as possible. I
>>>>>>> have been RM for 4.4.0 and one thing I don't want anymore is people
>>>>>>> share a 4.4-forward to cherry-pick commits from. It caused me a lot
>>>>>>> of
>>>>>>> headaches.
>>>>>>>
>>>>>>> The release is what drives the merges back to master according to
>>>>>>> git-flow. We can decide that we define a number of prerelease dates
>>>>>>> at
>>>>>>> which we merge as well. We don't have to do it at that date but can
>>>>>>> decide to do that the next day or week as well. This would kind of
>>>>>>> resemble Alena's #1 (as opposed to the more pure gitflow #2). An
>>>>>>> argument for #2 is that I don't think every customer greps the rpms
>>>>>>> for some release. I know our operators at Schuberg Philis
>>>>>>>investigate
>>>>>>> the code and check it out from git. They like to compare release
>>>>>>>and
>>>>>>> look at the latest easily. just checking out master would be very
>>>>>>> convenient for them. Of course they can check out a branch as well.
>>>>>>> But I doubt if they know exactly what to checkout then. I usually
>>>>>>>see
>>>>>>> them just look at the latest for a branch.
>>>>>>>
>>>>>>> All in all, I am very skeptic on whether this will work as planned.
>>>>>>> It
>>>>>>> is us who need to work neatly and only if we do that we can help
>>>>>>> ourselves with improving our process. I do feel that the present
>>>>>>>way
>>>>>>> of working, mainly the use forward branches but in general the lack
>>>>>>> of
>>>>>>> using branches to test individual changes, is hindering us in doing
>>>>>>> releases. The proposal at hand is very good but can only work if
>>>>>>> supported by the people that need to work with it. It doesn't do
>>>>>>>our
>>>>>>> release process for us. We still need to do it and not just program
>>>>>>> some code and check it in. That will never work in any process.
>>>>>>>Your
>>>>>>> code is not done until somebody somewhere finds it worth running it
>>>>>>> in
>>>>>>> a production environment. So let's keep discussing and educating
>>>>>>>each
>>>>>>> other.
>>>>>>>
>>>>>>> done ranting, feel free to react or contact me in person
>>>>>>> Daan
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <te...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle
>>>>>>>>> <Pr...@citrix.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I fail to understand how will this model help us with the
>>>>>>>>>> maintenance
>>>>>>>>>> releases?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> That's what gitflow support branches is for.
>>>>>>>>> I find this quite descriptive:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>>https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/Aw
>>>>>>>>>VH
>>>>>>>>> 06
>>>>>>>>> CuKT0J
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> For CloudStack we also keep working on prior releases and ship
>>>>>>>>>>out
>>>>>>>>>> maintenance releases.
>>>>>>>>>> I suppose we will be cutting the maintenance releases from the
>>>>>>>>>> release
>>>>>>>>>> branches? So we will have to keep around the release branches
>>>>>>>>>>for
>>>>>>>>>> that
>>>>>>>>>> purpose.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I've asked earlier, but what is the policy on old releases? How
>>>>>>>>> long
>>>>>>>>> do we
>>>>>>>>> support them?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Today (e.g. subject to change) we claim to support as a community
>>>>>>>> the
>>>>>>>> two
>>>>>>>> most recent feature releases. (for instance, we just stopped
>>>>>>>>support
>>>>>>>> the
>>>>>>>> 4.2.x line with the release of 4.4.0, and currently support 4.3.x
>>>>>>>> and
>>>>>>>> 4.4.x) We support those feature releases with bug fix releases
>>>>>>>>that
>>>>>>>> contain
>>>>>>>> no additional functionality.
>>>>>>>>
>>>>>>>> --David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Daan
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Daan
>>>>
>>>
>>> Regards,
>>> Rohit Yadav
>>> Software Architect, ShapeBlue
>>> M. +41 779015219 | rohit.yadav@shapeblue.com
>>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>>
>>>
>>>
>>> Find out more about ShapeBlue and our range of CloudStack related
>>>services
>>>
>>> IaaS Cloud Design &
>>> Build<http://shapeblue.com/iaas-cloud-design-and-build//>
>>> CSForge – rapid IaaS deployment
>>>framework<http://shapeblue.com/csforge/>
>>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>>> CloudStack Infrastructure
>>> Support<http://shapeblue.com/cloudstack-infrastructure-support/>
>>> CloudStack Bootcamp Training
>>> Courses<http://shapeblue.com/cloudstack-training/>
>>>
>>> This email and any attachments to it may be confidential and are
>>>intended
>>> solely for the use of the individual to whom it is addressed. Any views
>>> or opinions expressed are solely those of the author and do not
>>> necessarily represent those of Shape Blue Ltd or related companies. If
>>> you are not the intended recipient of this email, you must neither take
>>> any action based upon its contents, nor copy or show it to anyone.
>>>Please
>>> contact the sender if you believe you have received this email in
>>>error.
>>> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>>> Services India LLP is a company incorporated in India and is operated
>>> under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda
>>>is
>>> a company incorporated in Brasil and is operated under license from
>>>Shape
>>> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic
>>>of
>>> South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
>>> is a registered trademark.
>>
>
>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] git workflow

[Tracy Phillips <tr...@weberize.com>]

Any process is better than what is being used right now.

git-flow is just a proven process that is working for folks who use it.
That is a fact.

git-flow somewhat enforces a process, especially if you use the git-flow
plugin:

git flow feature start 2345-eye-candy

git flow feature publish etc, etc, etc.

It took me a bit to wrap my head around the concepts but when I did, it
*really* started to make sense. It does seem like a like for forking and
rebasing but that is what git is good at.

git-flow keeps things nice and tidy.

Re: [VOTE] git workflow

[Mike Tutkowski <mi...@solidfire.com>]

I admit that I'm a bit confused, as well, regarding the value of 'master'
if it only points to the most recently released version of CloudStack.

If you want the most recently released version, you can just go back in
time - as necessary - to arrive at the applicable commit.

I think the problem we really want to solve relates to the constant
instability of our work-in-progress branch (currently called 'master').
Without consideration for CI, our new 'develop' branch simply assumes all
of the faults currently associated with 'master'.

The way I see us taking a step toward solving the real problem is via what
Alena mention:

 * develop branch as a staging branch
 * merging develop branch to master on a regular basis after the CI test
passes
 * cut release branch from the stable master branch when its time for the
release


On Thu, Aug 7, 2014 at 2:44 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> Daan, thank you. Please see my comments inline.
>
>
> On 8/7/14, 1:19 PM, "Daan Hoogland" <da...@gmail.com> wrote:
>
> >On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
> ><Al...@citrix.com> wrote:
> >> Plus if you read the discussion below the article, you will see that
> >> people agree that this model doesn’t work well for the case when the
> >> product support maintenance for older releases, like CS does.
> >
> >Not at all, Alena. I don't agree that this model won't work for CS and
> >I think you are over estimating the amount of people that think so.
> >This model does work using support branches. It will work very well in
> >the CS case and is not very far removed from what we are doing right
> >now. There will always be port work when fixes in older versions need
> >to be made. You don't merge back support branches to tag the
> >maintainance release on the master branch. The fix-release-tag can
> >remain on the branche whether it is merged back or not. The witch hunt
> >on cherry picking is only perceived. There will be occasions it is
> >necessary but seldom so.
>
>
> Does it mean that our master branch will miss the fixes from support
> branches? Or you say we should cherry-pick them all on the top of the
> master branch.
>
> Again, I don’t see how maintaining master branch to reflect the latest
> release branch, can stabilize our release process. You will still continue
> to cut the release branches from *develop, which you can’t really call
> “stable” with this model.
>
>
> I’m still convinced that the best solution in our case would be
> introducing:
>
>  * develop branch as a staging branch
>  * merging develop branch to master on a regular basis after the CI test
> passes
>  * cut release branch from the stable master branch when its time for the
> release
>
>
> I’m really trying to find the advantages of git-flow model where master
> reflects the latest release branch, and can’t find any considering that in
> the CS we are still going to keep those release/support branches, and if
> people need the latest release code, they can simply get it from there.
>
> From the developer stand point, I would be more interested in getting the
> latest stable code, not the latest stable release. And with the model I
> propose, that would be the master branch you get the latest stable code
> from.
>
> From release management perspective, I would be more interested in cutting
> the release branches from the stable branch - gitflow suggests to cut it
> them from *develop branch rather than master - and *develop is not a
> stable branch. I don’t see the use of stable master branch during the
> release, as it reflects already released versions of the CS.
>
> May be I am missing the point. Would appreciate people explaining the
> purpose of a git-flow way of keeping master branch, to solve the existing
> CS problems. Just because “its a best practice for others” doesn’t sound
> very convincing.
>
>
> >
> >>
> >> "I think this model does not work for bugfixing in older releases,
> >>though.
> >> It messes up the neat ordering.
> >>
> >> 1. Say we have released Version 1.0.1 and later added features and
> >> released 1.1.0.
> >> 2. We discover a bug in 1.0.1 and want to fix it in both version
> >> 3. We have to add 1.0.2 after 1.1.0 in master and then directly atfer
> >>(or
> >> before) also 1.1.1.”
> >
> >No this is not true. You can branch 1.0.1 to make 1.0.2 and merge
> >after it is done,
>
>
>
>
> >
>
> Merge on a top of 1.1.0, which is the top of master branch?
>
>
>
>
> >next you can branch from 1.1.0 to make 1.1.1  and
> >merge that.
> >the commits that point to 1.0.2 and 1.1.1 wil not be
> >removed when deleting the branches and when the fixes are the same and
> >the merge of 1.0.2 is clean they 1.1.0 doesn't even have to be
> >branched. if 1.0.1 or 1.0.2 is a conflicting fix then yes. that is the
> >one exception. you don't merge back. you keep the support branch.
> >
> >This is not to far from what we do right now except that we keep old
> >branches preemptively right now.
> >
> >>
> >>
> >> Thanks,
> >> Alena.
> >>
> >> On 8/7/14, 10:19 AM, "Alena Prokharchyk" <Al...@citrix.com>
> >> wrote:
> >>
> >>>Not quite. That’s what the article suggests:
> >>>
> >>>"If you want to fix bugs for older releases or do any other develop
> >>>there,
> >>>you will fork a support branch from the appropriate commit in master
> >>>(you
> >>>will have all versions ever created there). These branches are just
> >>>started and not intended to be merged back to master nor develop. This
> >>>is
> >>>usually fine, as fixes to "ancient" releases or features requested by
> >>>customers to be implemented in "ancient" releases can't or should not go
> >>>back into master. If you still think, you want to port a fix to your
> >>>main
> >>>development line (represented by master and develop), just start a
> >>>hotfix,
> >>>cherry-pick your changes and finish the hotfix."
> >>>
> >>>
> >>>That doesn’t seem right to me - that NOT ALL the fixes done to
> >>>4.2.1/4.3.1
> >>>maintenance releases for example, will go back to master/develop? Plus
> >>>it
> >>>suggests “cherry-picking” stuff if we decide that some fixes worth being
> >>>back ported. Cherry-picking again? :) Defeats our cherry-pick witch hunt
> >>>purpose. I think ALL fixes done to any forked branch, should make it
> >>>into
> >>>master via merge.
> >>>
> >>>
> >>>On 8/7/14, 6:39 AM, "Tracy Phillips" <tr...@weberize.com> wrote:
> >>>
> >>>>Alena,
> >>>>
> >>>>Check this out and see if it would resolve your concern regarding
> >>>>maintaining multiple releases
> >>>>
> >>>>
> http://stackoverflow.com/questions/16562339/git-flow-and-master-with-mu
> >>>>lt
> >>>>i
> >>>>ple-parallel-release-branches
> >>>>
> >>>>git-flow uses support branches to support releases that are not on
> >>>>master.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
> >>>>Alena.Prokharchyk@citrix.com> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 8/6/14, 3:18 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
> >>>>>
> >>>>> >[top posting, apologies in advance]
> >>>>> >
> >>>>> >I am on vacation, so I will go straight to it :)
> >>>>> >
> >>>>> >This all discussion is not about gitflow specifically, it is about
> >>>>> >modifying our git workflow and our commit practices to something
> >>>>>more
> >>>>> >standard that can:
> >>>>> >
> >>>>> >- ultimately help improve quality (in itself it won't but it can
> >>>>>help
> >>>>>lay
> >>>>> >a foundation)
> >>>>> >- provide a stable master (it keeps breaking, it has regressions, it
> >>>>> >moves really fast etc..)
> >>>>> >- help cut releases
> >>>>> >
> >>>>> >Any committer has write privileges and can do whatever it wants to
> >>>>>the
> >>>>> >repos, so we need to get a nice big consensus on what problems we
> >>>>>are
> >>>>> >trying to solve, and how best to get there. So let's not make this a
> >>>>> >debate of yeah or neah gitflow.
> >>>>> >
> >>>>> >A better CI is coming but it's not yet there and we have no ETA.
> >>>>>Even
> >>>>> >with a CI infra in place, we will need commit discipline to improve
> >>>>> >quality (covertity, unitests, simulator tests). Changing our git
> >>>>>commit
> >>>>> >practices has no cost (just emails and self discipline), so can we
> >>>>>agree
> >>>>> >to do that first ?
> >>>>> >
> >>>>> >Here are couple high level things that I have in mind ( and I
> >>>>>confess
> >>>>>I
> >>>>> >have not read the entire threads on this yet and ti ma conflict with
> >>>>> >gitflow).
> >>>>> >
> >>>>> >-Master: what goes in master is only something that has been put
> >>>>>into
> >>>>>a
> >>>>> >release (aside from the maintenance releases fixes maybe...). Master
> >>>>>is
> >>>>> >the base for any release branch (until we get to 4.5, master will
> >>>>>still
> >>>>> >see some high churn to stabilize it, after 4.5 release branch is cut
> >>>>>we
> >>>>> >should enter into a stable master mode).
> >>>>>
> >>>>>
> >>>>> Sebastian, we can’t adopt this particular high level thing - when
> >>>>>master
> >>>>> reflects the latest stable release with the tags for all previous
> >>>>>releases
> >>>>> - because support maintenance releases for multiple CS versions in
> >>>>> parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1
> >>>>>can
> >>>>>be
> >>>>> released. And there is no way to merge them back to master w/o
> >>>>>breaking
> >>>>> the branch history.
> >>>>>
> >>>>> The model when master reflects the latest released branch, can be
> >>>>>used
> >>>>>for
> >>>>> the systems with rolling upgrades only, no maintenance releases for
> >>>>> previous versions of the software.
> >>>>>
> >>>>> To get more details, please read the latest email exchange (today’s)
> >>>>>on
> >>>>> git workflow between me/Rohit and Dave Nalley.
> >>>>>
> >>>>>
> >>>>>
> >>>>> >
> >>>>> >-Release: from the time a release branch is cut, features are only
> >>>>>merged
> >>>>> >by RM. hot fixes are only merged by RM. the RM is responsible for
> >>>>>the
> >>>>> >entire release process. Since he defines the scope and is the
> >>>>>primary
> >>>>> >person responsible to check BVT for the release branch he should be
> >>>>>able
> >>>>> >to release on-time. Major release gets merged back into master.
> >>>>> >
> >>>>> >-Devs: folks working on features and fixes are responsible to merge
> >>>>>into
> >>>>> >the develop branch and call the RM for a merge into a release branch
> >>>>> >(this may vary with gitflow, where release branch is cut from
> >>>>>develop)
> >>>>> >
> >>>>> >Once we have CI, it should run on every branch.
> >>>>> >
> >>>>> >-sebastien
> >>>>> >
> >>>>> >
> >>>>> >On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
> >>>>> ><Al...@citrix.com> wrote:
> >>>>> >
> >>>>> >> Edison, thank you for raising the concern about the BVT/CI.
> >>>>>Somebody
> >>>>> >> mentioned earlier that we should separate git workflow
> >>>>>implementation
> >>>>> >>from
> >>>>> >> the CI effort, but I do think we have to do in in conjunction.
> >>>>>Otherwise
> >>>>> >> what is the point in introducing staging/develop branch? If there
> >>>>>is
> >>>>>no
> >>>>> >> daily automation run verifying all the code merged from
> >>>>>hotFixes/feature
> >>>>> >> branches (and possibly reverting wrong checkins), we can as well
> >>>>>merge
> >>>>> >>the
> >>>>> >> code directly to master.
> >>>>> >>
> >>>>> >> -Alena.
> >>>>> >>
> >>>>> >> On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
> >>>>> >>
> >>>>> >>>
> >>>>> >>>
> >>>>> >>>> -----Original Message-----
> >>>>> >>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> >>>>> >>>> Sent: Wednesday, August 06, 2014 12:59 PM
> >>>>> >>>> To: dev@cloudstack.apache.org
> >>>>> >>>> Subject: Re: [VOTE] git workflow
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
> >>>>> >>>>
> >>>>> >>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
> >>>>> >>>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>> >>>>>
> >>>>> >>>>>> Agree with you, Rohit. The changes to the git model we use,
> >>>>>are
> >>>>> >>>>>> needed  indeed. But we should address only the problems that
> >>>>>CS
> >>>>> >>>>>>faces,
> >>>>> >>>>>> and the  main problem - quality control. The proposal should
> >>>>>be
> >>>>> >>>>>> limited just to the  changes that are really needed for the
> >>>>>CS,
> >>>>>and
> >>>>> >>>>>> that will work with the  current CS model (minor maintenance
> >>>>> >>>>>>releases
> >>>>> >>>>>> support is a part of it)
> >>>>> >>>>>>
> >>>>> >>>>>>
> >>>>> >>>>>
> >>>>> >>>>> Theoretically you don't really have to change anything other
> >>>>>than
> >>>>> >>>>> merging instead of cherry picking.
> >>>>> >>>>> That is the main issue from a release perspective.
> >>>>> >>>>>
> >>>>> >>>>> But I still think there are good reasons to do so;
> >>>>> >>>>>
> >>>>> >>>>> 1) using a well known way of handling code/releases instantly
> >>>>>tells
> >>>>> >>>>>new
> >>>>> >>>>> contributors / committers how we work. add to the fact that
> >>>>>there
> >>>>> >>>>> exists tools to help doing this correctly is a bonus.
> >>>>> >>>>> 2) having a known stable (atleast in theory) release as master
> >>>>>is
> >>>>> >>>>>good
> >>>>> >>>>> practice. although not many users will be running from git, i
> >>>>>still
> >>>>> >>>>> consider it to be good practice.
> >>>>> >>>>> 3) there is a huge belief in this thread/discussion that as
> >>>>>long
> >>>>>as
> >>>>> >>>>> something passes CI / BVT it is considered stable. The fact is
> >>>>>that
> >>>>> >>>>>it
> >>>>> >>>>> is not. Take the recent 4.4 release as a good example, where a
> >>>>>new
> >>>>> >>>>> install was not working at all at the point of release. Now,
> >>>>>this
> >>>>>is
> >>>>> >>>>> more a CI / test coverage issue than git workflow issue, but i
> >>>>>find
> >>>>> >>>>>it
> >>>>> >>>>> weird to use as an argument for not improving the workflow.
> >>>>> >>>>>
> >>>>> >>>>> --
> >>>>> >>>>> Erik
> >>>>> >>>>
> >>>>> >>>> I¹m not arguing against keeping master release stable; I
> >>>>>advocate
> >>>>>for
> >>>>> >>>> it.
> >>>>> >>>
> >>>>> >>> +1, we need to take action to make sure master is stable. Frankly
> >>>>> >>> speaking,
> >>>>> >>> I don't want to fix the regression on the master, I assume nobody
> >>>>>want
> >>>>> >>>to
> >>>>> >>> do that.
> >>>>> >>> Here is the list of regression issues(not introduced by myself) I
> >>>>>fixed
> >>>>> >>> on master after 4.4:
> >>>>> >>>
> >>>>> >>> CLOUDSTACK-7123
> >>>>> >>> CLOUDSTACK-7110
> >>>>> >>> CLOUDSTACK-7166
> >>>>> >>> CLOUDSTACK-7164
> >>>>> >>> Most of this issues will be caught even by a simulator BVT. I
> >>>>>want
> >>>>>to
> >>>>> >>> make it clear, that,
> >>>>> >>> If we don't take action to reduce/eliminate the regression as
> >>>>>much
> >>>>>as
> >>>>> >>> possible in the future, I will not fix any of this regression
> >>>>>issues.
> >>>>> >>> I remember there is discussion about setting up a staging branch,
> >>>>>run
> >>>>> >>>BVT
> >>>>> >>> against it for each commit, what's the conclusion if any? Why so
> >>>>> >>> difficult to make it happen? Is there anything I can help to make
> >>>>>it
> >>>>> >>> happen?
> >>>>> >>>
> >>>>> >>>> But we can¹t adopt git workflow way of keeping master branch to
> >>>>>be
> >>>>>a
> >>>>> >>>> reflection of the latest release branch. It will not work with
> >>>>>our
> >>>>>way
> >>>>> >>>> of
> >>>>> >>>> handling maintenance releases for multiple versions of CS - see
> >>>>> >>>>another
> >>>>> >>>> thread.
> >>>>> >>>
> >>>>> >>>
> >>>>> >>> +1, I'll -1 on any of proposal, if it doesn't solve problem most
> >>>>>of
> >>>>>us
> >>>>> >>> are concerning about.
> >>>>> >>>
> >>>>> >>>>
> >>>>> >>>> Instead, master branch should reflect the latest code that
> >>>>>passed
> >>>>>the
> >>>>> >>>> CI test
> >>>>> >>>> (the code merged from *develop after CI passes). The release
> >>>>>branches
> >>>>> >>>> should be cut from stable master branch - it will ensure that we
> >>>>>won¹t
> >>>>> >>>> face
> >>>>> >>>> last minute blockers as for 4.4, because master IS a stable
> >>>>>branch.
> >>>>> >>>> And yes, we should do merges instead of cherry picking.
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>>>
> >>>>> >>>
> >>>>> >>
> >>>>> >
> >>>>>
> >>>>>
> >>>
> >>
> >
> >
> >
> >--
> >Daan
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Erik, addressing "What's the downside of having master represent the
latest released version?²

No real downside (rather than the pain when it comes to managing
maintenance releases for earlier versions of CS), but what are the
advantages really? 

If you are the user who wants to get the latest stable release, you just
get it from the release branch (or specific tag on that branch if you want
a particular minor release), the release branch that - again - we must
keep around because of subsequent maintenance releases that we support in
CS. Unlike in git-workflow, when release branch is removed right after its
merged to master.

And if you are a RM who wants to cut the release, you do it from the
stable branch with the latest code. And that branch won¹t be master.

So why implement something that doesn¹t serve any practical purpose for
CS? I don¹t argue against other items of git-workflow (merges vs
cherry-picks, feature/hotfix branches), my main concern is about master
branch maintenance.

=Alena.

On 8/7/14, 2:17 PM, "Erik Weber" <te...@gmail.com> wrote:

>On Thu, Aug 7, 2014 at 10:44 PM, Alena Prokharchyk <
>Alena.Prokharchyk@citrix.com> wrote:
>
>> Daan, thank you. Please see my comments inline.
>>
>>
>> On 8/7/14, 1:19 PM, "Daan Hoogland" <da...@gmail.com> wrote:
>>
>> >On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
>> ><Al...@citrix.com> wrote:
>> >> Plus if you read the discussion below the article, you will see that
>> >> people agree that this model doesn¹t work well for the case when the
>> >> product support maintenance for older releases, like CS does.
>> >
>> >Not at all, Alena. I don't agree that this model won't work for CS and
>> >I think you are over estimating the amount of people that think so.
>> >This model does work using support branches. It will work very well in
>> >the CS case and is not very far removed from what we are doing right
>> >now. There will always be port work when fixes in older versions need
>> >to be made. You don't merge back support branches to tag the
>> >maintainance release on the master branch. The fix-release-tag can
>> >remain on the branche whether it is merged back or not. The witch hunt
>> >on cherry picking is only perceived. There will be occasions it is
>> >necessary but seldom so.
>>
>>
>> Does it mean that our master branch will miss the fixes from support
>> branches? Or you say we should cherry-pick them all on the top of the
>> master branch.
>>
>
>
>'master' reflects the latest released version. If that release misses the
>fix, then master does as well.
>For master to have it you would either roll out a new version or hotfix
>it.
>
>
>
>> Again, I don¹t see how maintaining master branch to reflect the latest
>> release branch, can stabilize our release process. You will still
>>continue
>> to cut the release branches from *develop, which you can¹t really call
>> ³stable² with this model.
>>
>>
>It doesn't. master could just as easily have been called 'stable' or
>'latest'.
>
>
>>
>> I¹m still convinced that the best solution in our case would be
>> introducing:
>>
>>  * develop branch as a staging branch
>>
>
>develop is the staging branch in gitflow as well, you do your development
>in feature branches.
>when your feature is done and passes CI you merge to develop.
>
> * merging develop branch to master on a regular basis after the CI test
>> passes
>>
>
>
>there's no guarantee that it's stable at all, CI can only cover so much.
>besides, this is what gitflow proposes, except that you merge from your
>feature branch to develop, instead of from develop to master.
>
>
>
>>  * cut release branch from the stable master branch when its time for
>>the
>> release
>>
>
>see previous, besides if the only thing deeming if master is stable or not
>is CI, then you might as well cut from develop
>
>
>
>> I¹m really trying to find the advantages of git-flow model where master
>> reflects the latest release branch, and can¹t find any considering that
>>in
>> the CS we are still going to keep those release/support branches, and if
>> people need the latest release code, they can simply get it from there.
>>
>>
>What's the downside of having master represent the latest released
>version?
>
>
>> From the developer stand point, I would be more interested in getting
>>the
>> latest stable code, not the latest stable release. And with the model I
>> propose, that would be the master branch you get the latest stable code
>> from.
>>
>
>So you have to do a 'git checkout develop' first. unless you use the
>gitflow tools,
>then you do a simple 'gitflow feature start <feature-name, bugid or
>similar>' and don't really care
>about branch names at all.
>
>
>> From release management perspective, I would be more interested in
>>cutting
>> the release branches from the stable branch - gitflow suggests to cut it
>> them from *develop branch rather than master - and *develop is not a
>> stable branch. I don¹t see the use of stable master branch during the
>> release, as it reflects already released versions of the CS.
>>
>
>develop should be as stable as the master you propose, after all they
>should contain the same code.
>
>
>
>> May be I am missing the point. Would appreciate people explaining the
>> purpose of a git-flow way of keeping master branch, to solve the
>>existing
>> CS problems. Just because ³its a best practice for others² doesn¹t sound
>> very convincing.
>>
>
>
>If the master branch is what confuses you the most, then forget about
>master branch.
>As a developer you are not really interested in it anyway, you never
>really
>commit to it besides new releases / hotfixes to the latest release.
>Think of develop as your master and treat it like that, and think of
>master
>as a shortcut to the latest release tag.
>
>-- 
>Erik

Re: [VOTE] git workflow

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

On Thu, Aug 7, 2014 at 10:44 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> Daan, thank you. Please see my comments inline.
>
>
> On 8/7/14, 1:19 PM, "Daan Hoogland" <da...@gmail.com> wrote:
>
> >On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
> ><Al...@citrix.com> wrote:
> >> Plus if you read the discussion below the article, you will see that
> >> people agree that this model doesn’t work well for the case when the
> >> product support maintenance for older releases, like CS does.
> >
> >Not at all, Alena. I don't agree that this model won't work for CS and
> >I think you are over estimating the amount of people that think so.
> >This model does work using support branches. It will work very well in
> >the CS case and is not very far removed from what we are doing right
> >now. There will always be port work when fixes in older versions need
> >to be made. You don't merge back support branches to tag the
> >maintainance release on the master branch. The fix-release-tag can
> >remain on the branche whether it is merged back or not. The witch hunt
> >on cherry picking is only perceived. There will be occasions it is
> >necessary but seldom so.
>
>
> Does it mean that our master branch will miss the fixes from support
> branches? Or you say we should cherry-pick them all on the top of the
> master branch.
>


'master' reflects the latest released version. If that release misses the
fix, then master does as well.
For master to have it you would either roll out a new version or hotfix it.



> Again, I don’t see how maintaining master branch to reflect the latest
> release branch, can stabilize our release process. You will still continue
> to cut the release branches from *develop, which you can’t really call
> “stable” with this model.
>
>
It doesn't. master could just as easily have been called 'stable' or
'latest'.


>
> I’m still convinced that the best solution in our case would be
> introducing:
>
>  * develop branch as a staging branch
>

develop is the staging branch in gitflow as well, you do your development
in feature branches.
when your feature is done and passes CI you merge to develop.

 * merging develop branch to master on a regular basis after the CI test
> passes
>


there's no guarantee that it's stable at all, CI can only cover so much.
besides, this is what gitflow proposes, except that you merge from your
feature branch to develop, instead of from develop to master.



>  * cut release branch from the stable master branch when its time for the
> release
>

see previous, besides if the only thing deeming if master is stable or not
is CI, then you might as well cut from develop



> I’m really trying to find the advantages of git-flow model where master
> reflects the latest release branch, and can’t find any considering that in
> the CS we are still going to keep those release/support branches, and if
> people need the latest release code, they can simply get it from there.
>
>
What's the downside of having master represent the latest released version?


> From the developer stand point, I would be more interested in getting the
> latest stable code, not the latest stable release. And with the model I
> propose, that would be the master branch you get the latest stable code
> from.
>

So you have to do a 'git checkout develop' first. unless you use the
gitflow tools,
then you do a simple 'gitflow feature start <feature-name, bugid or
similar>' and don't really care
about branch names at all.


> From release management perspective, I would be more interested in cutting
> the release branches from the stable branch - gitflow suggests to cut it
> them from *develop branch rather than master - and *develop is not a
> stable branch. I don’t see the use of stable master branch during the
> release, as it reflects already released versions of the CS.
>

develop should be as stable as the master you propose, after all they
should contain the same code.



> May be I am missing the point. Would appreciate people explaining the
> purpose of a git-flow way of keeping master branch, to solve the existing
> CS problems. Just because “its a best practice for others” doesn’t sound
> very convincing.
>


If the master branch is what confuses you the most, then forget about
master branch.
As a developer you are not really interested in it anyway, you never really
commit to it besides new releases / hotfixes to the latest release.
Think of develop as your master and treat it like that, and think of master
as a shortcut to the latest release tag.

-- 
Erik

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Daan, thank you. Please see my comments inline.


On 8/7/14, 1:19 PM, "Daan Hoogland" <da...@gmail.com> wrote:

>On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
><Al...@citrix.com> wrote:
>> Plus if you read the discussion below the article, you will see that
>> people agree that this model doesn’t work well for the case when the
>> product support maintenance for older releases, like CS does.
>
>Not at all, Alena. I don't agree that this model won't work for CS and
>I think you are over estimating the amount of people that think so.
>This model does work using support branches. It will work very well in
>the CS case and is not very far removed from what we are doing right
>now. There will always be port work when fixes in older versions need
>to be made. You don't merge back support branches to tag the
>maintainance release on the master branch. The fix-release-tag can
>remain on the branche whether it is merged back or not. The witch hunt
>on cherry picking is only perceived. There will be occasions it is
>necessary but seldom so.


Does it mean that our master branch will miss the fixes from support
branches? Or you say we should cherry-pick them all on the top of the
master branch.

Again, I don’t see how maintaining master branch to reflect the latest
release branch, can stabilize our release process. You will still continue
to cut the release branches from *develop, which you can’t really call
“stable” with this model.


I’m still convinced that the best solution in our case would be
introducing:

 * develop branch as a staging branch
 * merging develop branch to master on a regular basis after the CI test
passes
 * cut release branch from the stable master branch when its time for the
release


I’m really trying to find the advantages of git-flow model where master
reflects the latest release branch, and can’t find any considering that in
the CS we are still going to keep those release/support branches, and if
people need the latest release code, they can simply get it from there.

From the developer stand point, I would be more interested in getting the
latest stable code, not the latest stable release. And with the model I
propose, that would be the master branch you get the latest stable code
from.

From release management perspective, I would be more interested in cutting
the release branches from the stable branch - gitflow suggests to cut it
them from *develop branch rather than master - and *develop is not a
stable branch. I don’t see the use of stable master branch during the
release, as it reflects already released versions of the CS.

May be I am missing the point. Would appreciate people explaining the
purpose of a git-flow way of keeping master branch, to solve the existing
CS problems. Just because “its a best practice for others” doesn’t sound
very convincing. 


>
>>
>> "I think this model does not work for bugfixing in older releases,
>>though.
>> It messes up the neat ordering.
>>
>> 1. Say we have released Version 1.0.1 and later added features and
>> released 1.1.0.
>> 2. We discover a bug in 1.0.1 and want to fix it in both version
>> 3. We have to add 1.0.2 after 1.1.0 in master and then directly atfer
>>(or
>> before) also 1.1.1.”
>
>No this is not true. You can branch 1.0.1 to make 1.0.2 and merge
>after it is done,




> 

Merge on a top of 1.1.0, which is the top of master branch?




>next you can branch from 1.1.0 to make 1.1.1  and
>merge that.
>the commits that point to 1.0.2 and 1.1.1 wil not be
>removed when deleting the branches and when the fixes are the same and
>the merge of 1.0.2 is clean they 1.1.0 doesn't even have to be
>branched. if 1.0.1 or 1.0.2 is a conflicting fix then yes. that is the
>one exception. you don't merge back. you keep the support branch.
>
>This is not to far from what we do right now except that we keep old
>branches preemptively right now.
>
>>
>>
>> Thanks,
>> Alena.
>>
>> On 8/7/14, 10:19 AM, "Alena Prokharchyk" <Al...@citrix.com>
>> wrote:
>>
>>>Not quite. That’s what the article suggests:
>>>
>>>"If you want to fix bugs for older releases or do any other develop
>>>there,
>>>you will fork a support branch from the appropriate commit in master
>>>(you
>>>will have all versions ever created there). These branches are just
>>>started and not intended to be merged back to master nor develop. This
>>>is
>>>usually fine, as fixes to "ancient" releases or features requested by
>>>customers to be implemented in "ancient" releases can't or should not go
>>>back into master. If you still think, you want to port a fix to your
>>>main
>>>development line (represented by master and develop), just start a
>>>hotfix,
>>>cherry-pick your changes and finish the hotfix."
>>>
>>>
>>>That doesn’t seem right to me - that NOT ALL the fixes done to
>>>4.2.1/4.3.1
>>>maintenance releases for example, will go back to master/develop? Plus
>>>it
>>>suggests “cherry-picking” stuff if we decide that some fixes worth being
>>>back ported. Cherry-picking again? :) Defeats our cherry-pick witch hunt
>>>purpose. I think ALL fixes done to any forked branch, should make it
>>>into
>>>master via merge.
>>>
>>>
>>>On 8/7/14, 6:39 AM, "Tracy Phillips" <tr...@weberize.com> wrote:
>>>
>>>>Alena,
>>>>
>>>>Check this out and see if it would resolve your concern regarding
>>>>maintaining multiple releases
>>>>
>>>>http://stackoverflow.com/questions/16562339/git-flow-and-master-with-mu
>>>>lt
>>>>i
>>>>ple-parallel-release-branches
>>>>
>>>>git-flow uses support branches to support releases that are not on
>>>>master.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
>>>>Alena.Prokharchyk@citrix.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 8/6/14, 3:18 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>>>>
>>>>> >[top posting, apologies in advance]
>>>>> >
>>>>> >I am on vacation, so I will go straight to it :)
>>>>> >
>>>>> >This all discussion is not about gitflow specifically, it is about
>>>>> >modifying our git workflow and our commit practices to something
>>>>>more
>>>>> >standard that can:
>>>>> >
>>>>> >- ultimately help improve quality (in itself it won't but it can
>>>>>help
>>>>>lay
>>>>> >a foundation)
>>>>> >- provide a stable master (it keeps breaking, it has regressions, it
>>>>> >moves really fast etc..)
>>>>> >- help cut releases
>>>>> >
>>>>> >Any committer has write privileges and can do whatever it wants to
>>>>>the
>>>>> >repos, so we need to get a nice big consensus on what problems we
>>>>>are
>>>>> >trying to solve, and how best to get there. So let's not make this a
>>>>> >debate of yeah or neah gitflow.
>>>>> >
>>>>> >A better CI is coming but it's not yet there and we have no ETA.
>>>>>Even
>>>>> >with a CI infra in place, we will need commit discipline to improve
>>>>> >quality (covertity, unitests, simulator tests). Changing our git
>>>>>commit
>>>>> >practices has no cost (just emails and self discipline), so can we
>>>>>agree
>>>>> >to do that first ?
>>>>> >
>>>>> >Here are couple high level things that I have in mind ( and I
>>>>>confess
>>>>>I
>>>>> >have not read the entire threads on this yet and ti ma conflict with
>>>>> >gitflow).
>>>>> >
>>>>> >-Master: what goes in master is only something that has been put
>>>>>into
>>>>>a
>>>>> >release (aside from the maintenance releases fixes maybe...). Master
>>>>>is
>>>>> >the base for any release branch (until we get to 4.5, master will
>>>>>still
>>>>> >see some high churn to stabilize it, after 4.5 release branch is cut
>>>>>we
>>>>> >should enter into a stable master mode).
>>>>>
>>>>>
>>>>> Sebastian, we can’t adopt this particular high level thing - when
>>>>>master
>>>>> reflects the latest stable release with the tags for all previous
>>>>>releases
>>>>> - because support maintenance releases for multiple CS versions in
>>>>> parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1
>>>>>can
>>>>>be
>>>>> released. And there is no way to merge them back to master w/o
>>>>>breaking
>>>>> the branch history.
>>>>>
>>>>> The model when master reflects the latest released branch, can be
>>>>>used
>>>>>for
>>>>> the systems with rolling upgrades only, no maintenance releases for
>>>>> previous versions of the software.
>>>>>
>>>>> To get more details, please read the latest email exchange (today’s)
>>>>>on
>>>>> git workflow between me/Rohit and Dave Nalley.
>>>>>
>>>>>
>>>>>
>>>>> >
>>>>> >-Release: from the time a release branch is cut, features are only
>>>>>merged
>>>>> >by RM. hot fixes are only merged by RM. the RM is responsible for
>>>>>the
>>>>> >entire release process. Since he defines the scope and is the
>>>>>primary
>>>>> >person responsible to check BVT for the release branch he should be
>>>>>able
>>>>> >to release on-time. Major release gets merged back into master.
>>>>> >
>>>>> >-Devs: folks working on features and fixes are responsible to merge
>>>>>into
>>>>> >the develop branch and call the RM for a merge into a release branch
>>>>> >(this may vary with gitflow, where release branch is cut from
>>>>>develop)
>>>>> >
>>>>> >Once we have CI, it should run on every branch.
>>>>> >
>>>>> >-sebastien
>>>>> >
>>>>> >
>>>>> >On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
>>>>> ><Al...@citrix.com> wrote:
>>>>> >
>>>>> >> Edison, thank you for raising the concern about the BVT/CI.
>>>>>Somebody
>>>>> >> mentioned earlier that we should separate git workflow
>>>>>implementation
>>>>> >>from
>>>>> >> the CI effort, but I do think we have to do in in conjunction.
>>>>>Otherwise
>>>>> >> what is the point in introducing staging/develop branch? If there
>>>>>is
>>>>>no
>>>>> >> daily automation run verifying all the code merged from
>>>>>hotFixes/feature
>>>>> >> branches (and possibly reverting wrong checkins), we can as well
>>>>>merge
>>>>> >>the
>>>>> >> code directly to master.
>>>>> >>
>>>>> >> -Alena.
>>>>> >>
>>>>> >> On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
>>>>> >>
>>>>> >>>
>>>>> >>>
>>>>> >>>> -----Original Message-----
>>>>> >>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>>>>> >>>> Sent: Wednesday, August 06, 2014 12:59 PM
>>>>> >>>> To: dev@cloudstack.apache.org
>>>>> >>>> Subject: Re: [VOTE] git workflow
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
>>>>> >>>>
>>>>> >>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>>>>> >>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>>> >>>>>
>>>>> >>>>>> Agree with you, Rohit. The changes to the git model we use,
>>>>>are
>>>>> >>>>>> needed  indeed. But we should address only the problems that
>>>>>CS
>>>>> >>>>>>faces,
>>>>> >>>>>> and the  main problem - quality control. The proposal should
>>>>>be
>>>>> >>>>>> limited just to the  changes that are really needed for the
>>>>>CS,
>>>>>and
>>>>> >>>>>> that will work with the  current CS model (minor maintenance
>>>>> >>>>>>releases
>>>>> >>>>>> support is a part of it)
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>
>>>>> >>>>> Theoretically you don't really have to change anything other
>>>>>than
>>>>> >>>>> merging instead of cherry picking.
>>>>> >>>>> That is the main issue from a release perspective.
>>>>> >>>>>
>>>>> >>>>> But I still think there are good reasons to do so;
>>>>> >>>>>
>>>>> >>>>> 1) using a well known way of handling code/releases instantly
>>>>>tells
>>>>> >>>>>new
>>>>> >>>>> contributors / committers how we work. add to the fact that
>>>>>there
>>>>> >>>>> exists tools to help doing this correctly is a bonus.
>>>>> >>>>> 2) having a known stable (atleast in theory) release as master
>>>>>is
>>>>> >>>>>good
>>>>> >>>>> practice. although not many users will be running from git, i
>>>>>still
>>>>> >>>>> consider it to be good practice.
>>>>> >>>>> 3) there is a huge belief in this thread/discussion that as
>>>>>long
>>>>>as
>>>>> >>>>> something passes CI / BVT it is considered stable. The fact is
>>>>>that
>>>>> >>>>>it
>>>>> >>>>> is not. Take the recent 4.4 release as a good example, where a
>>>>>new
>>>>> >>>>> install was not working at all at the point of release. Now,
>>>>>this
>>>>>is
>>>>> >>>>> more a CI / test coverage issue than git workflow issue, but i
>>>>>find
>>>>> >>>>>it
>>>>> >>>>> weird to use as an argument for not improving the workflow.
>>>>> >>>>>
>>>>> >>>>> --
>>>>> >>>>> Erik
>>>>> >>>>
>>>>> >>>> I¹m not arguing against keeping master release stable; I
>>>>>advocate
>>>>>for
>>>>> >>>> it.
>>>>> >>>
>>>>> >>> +1, we need to take action to make sure master is stable. Frankly
>>>>> >>> speaking,
>>>>> >>> I don't want to fix the regression on the master, I assume nobody
>>>>>want
>>>>> >>>to
>>>>> >>> do that.
>>>>> >>> Here is the list of regression issues(not introduced by myself) I
>>>>>fixed
>>>>> >>> on master after 4.4:
>>>>> >>>
>>>>> >>> CLOUDSTACK-7123
>>>>> >>> CLOUDSTACK-7110
>>>>> >>> CLOUDSTACK-7166
>>>>> >>> CLOUDSTACK-7164
>>>>> >>> Most of this issues will be caught even by a simulator BVT. I
>>>>>want
>>>>>to
>>>>> >>> make it clear, that,
>>>>> >>> If we don't take action to reduce/eliminate the regression as
>>>>>much
>>>>>as
>>>>> >>> possible in the future, I will not fix any of this regression
>>>>>issues.
>>>>> >>> I remember there is discussion about setting up a staging branch,
>>>>>run
>>>>> >>>BVT
>>>>> >>> against it for each commit, what's the conclusion if any? Why so
>>>>> >>> difficult to make it happen? Is there anything I can help to make
>>>>>it
>>>>> >>> happen?
>>>>> >>>
>>>>> >>>> But we can¹t adopt git workflow way of keeping master branch to
>>>>>be
>>>>>a
>>>>> >>>> reflection of the latest release branch. It will not work with
>>>>>our
>>>>>way
>>>>> >>>> of
>>>>> >>>> handling maintenance releases for multiple versions of CS - see
>>>>> >>>>another
>>>>> >>>> thread.
>>>>> >>>
>>>>> >>>
>>>>> >>> +1, I'll -1 on any of proposal, if it doesn't solve problem most
>>>>>of
>>>>>us
>>>>> >>> are concerning about.
>>>>> >>>
>>>>> >>>>
>>>>> >>>> Instead, master branch should reflect the latest code that
>>>>>passed
>>>>>the
>>>>> >>>> CI test
>>>>> >>>> (the code merged from *develop after CI passes). The release
>>>>>branches
>>>>> >>>> should be cut from stable master branch - it will ensure that we
>>>>>won¹t
>>>>> >>>> face
>>>>> >>>> last minute blockers as for 4.4, because master IS a stable
>>>>>branch.
>>>>> >>>> And yes, we should do merges instead of cherry picking.
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>>
>>>>> >>>
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>
>>
>
>
>
>-- 
>Daan

Re: [VOTE] git workflow

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

On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
<Al...@citrix.com> wrote:
> Plus if you read the discussion below the article, you will see that
> people agree that this model doesn’t work well for the case when the
> product support maintenance for older releases, like CS does.

Not at all, Alena. I don't agree that this model won't work for CS and
I think you are over estimating the amount of people that think so.
This model does work using support branches. It will work very well in
the CS case and is not very far removed from what we are doing right
now. There will always be port work when fixes in older versions need
to be made. You don't merge back support branches to tag the
maintainance release on the master branch. The fix-release-tag can
remain on the branche whether it is merged back or not. The witch hunt
on cherry picking is only perceived. There will be occasions it is
necessary but seldom so.

>
> "I think this model does not work for bugfixing in older releases, though.
> It messes up the neat ordering.
>
> 1. Say we have released Version 1.0.1 and later added features and
> released 1.1.0.
> 2. We discover a bug in 1.0.1 and want to fix it in both version
> 3. We have to add 1.0.2 after 1.1.0 in master and then directly atfer (or
> before) also 1.1.1.”

No this is not true. You can branch 1.0.1 to make 1.0.2 and merge
after it is done, next you can branch from 1.1.0 to make 1.1.1  and
merge that. the commits that point to 1.0.2 and 1.1.1 wil not be
removed when deleting the branches and when the fixes are the same and
the merge of 1.0.2 is clean they 1.1.0 doesn't even have to be
branched. if 1.0.1 or 1.0.2 is a conflicting fix then yes. that is the
one exception. you don't merge back. you keep the support branch.

This is not to far from what we do right now except that we keep old
branches preemptively right now.

>
>
> Thanks,
> Alena.
>
> On 8/7/14, 10:19 AM, "Alena Prokharchyk" <Al...@citrix.com>
> wrote:
>
>>Not quite. That’s what the article suggests:
>>
>>"If you want to fix bugs for older releases or do any other develop there,
>>you will fork a support branch from the appropriate commit in master (you
>>will have all versions ever created there). These branches are just
>>started and not intended to be merged back to master nor develop. This is
>>usually fine, as fixes to "ancient" releases or features requested by
>>customers to be implemented in "ancient" releases can't or should not go
>>back into master. If you still think, you want to port a fix to your main
>>development line (represented by master and develop), just start a hotfix,
>>cherry-pick your changes and finish the hotfix."
>>
>>
>>That doesn’t seem right to me - that NOT ALL the fixes done to 4.2.1/4.3.1
>>maintenance releases for example, will go back to master/develop? Plus it
>>suggests “cherry-picking” stuff if we decide that some fixes worth being
>>back ported. Cherry-picking again? :) Defeats our cherry-pick witch hunt
>>purpose. I think ALL fixes done to any forked branch, should make it into
>>master via merge.
>>
>>
>>On 8/7/14, 6:39 AM, "Tracy Phillips" <tr...@weberize.com> wrote:
>>
>>>Alena,
>>>
>>>Check this out and see if it would resolve your concern regarding
>>>maintaining multiple releases
>>>
>>>http://stackoverflow.com/questions/16562339/git-flow-and-master-with-mult
>>>i
>>>ple-parallel-release-branches
>>>
>>>git-flow uses support branches to support releases that are not on
>>>master.
>>>
>>>
>>>
>>>
>>>
>>>On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
>>>Alena.Prokharchyk@citrix.com> wrote:
>>>
>>>>
>>>>
>>>> On 8/6/14, 3:18 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>>>
>>>> >[top posting, apologies in advance]
>>>> >
>>>> >I am on vacation, so I will go straight to it :)
>>>> >
>>>> >This all discussion is not about gitflow specifically, it is about
>>>> >modifying our git workflow and our commit practices to something more
>>>> >standard that can:
>>>> >
>>>> >- ultimately help improve quality (in itself it won't but it can help
>>>>lay
>>>> >a foundation)
>>>> >- provide a stable master (it keeps breaking, it has regressions, it
>>>> >moves really fast etc..)
>>>> >- help cut releases
>>>> >
>>>> >Any committer has write privileges and can do whatever it wants to the
>>>> >repos, so we need to get a nice big consensus on what problems we are
>>>> >trying to solve, and how best to get there. So let's not make this a
>>>> >debate of yeah or neah gitflow.
>>>> >
>>>> >A better CI is coming but it's not yet there and we have no ETA. Even
>>>> >with a CI infra in place, we will need commit discipline to improve
>>>> >quality (covertity, unitests, simulator tests). Changing our git
>>>>commit
>>>> >practices has no cost (just emails and self discipline), so can we
>>>>agree
>>>> >to do that first ?
>>>> >
>>>> >Here are couple high level things that I have in mind ( and I confess
>>>>I
>>>> >have not read the entire threads on this yet and ti ma conflict with
>>>> >gitflow).
>>>> >
>>>> >-Master: what goes in master is only something that has been put into
>>>>a
>>>> >release (aside from the maintenance releases fixes maybe...). Master
>>>>is
>>>> >the base for any release branch (until we get to 4.5, master will
>>>>still
>>>> >see some high churn to stabilize it, after 4.5 release branch is cut
>>>>we
>>>> >should enter into a stable master mode).
>>>>
>>>>
>>>> Sebastian, we can’t adopt this particular high level thing - when
>>>>master
>>>> reflects the latest stable release with the tags for all previous
>>>>releases
>>>> - because support maintenance releases for multiple CS versions in
>>>> parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1 can
>>>>be
>>>> released. And there is no way to merge them back to master w/o breaking
>>>> the branch history.
>>>>
>>>> The model when master reflects the latest released branch, can be used
>>>>for
>>>> the systems with rolling upgrades only, no maintenance releases for
>>>> previous versions of the software.
>>>>
>>>> To get more details, please read the latest email exchange (today’s) on
>>>> git workflow between me/Rohit and Dave Nalley.
>>>>
>>>>
>>>>
>>>> >
>>>> >-Release: from the time a release branch is cut, features are only
>>>>merged
>>>> >by RM. hot fixes are only merged by RM. the RM is responsible for the
>>>> >entire release process. Since he defines the scope and is the primary
>>>> >person responsible to check BVT for the release branch he should be
>>>>able
>>>> >to release on-time. Major release gets merged back into master.
>>>> >
>>>> >-Devs: folks working on features and fixes are responsible to merge
>>>>into
>>>> >the develop branch and call the RM for a merge into a release branch
>>>> >(this may vary with gitflow, where release branch is cut from develop)
>>>> >
>>>> >Once we have CI, it should run on every branch.
>>>> >
>>>> >-sebastien
>>>> >
>>>> >
>>>> >On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
>>>> ><Al...@citrix.com> wrote:
>>>> >
>>>> >> Edison, thank you for raising the concern about the BVT/CI. Somebody
>>>> >> mentioned earlier that we should separate git workflow
>>>>implementation
>>>> >>from
>>>> >> the CI effort, but I do think we have to do in in conjunction.
>>>>Otherwise
>>>> >> what is the point in introducing staging/develop branch? If there is
>>>>no
>>>> >> daily automation run verifying all the code merged from
>>>>hotFixes/feature
>>>> >> branches (and possibly reverting wrong checkins), we can as well
>>>>merge
>>>> >>the
>>>> >> code directly to master.
>>>> >>
>>>> >> -Alena.
>>>> >>
>>>> >> On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
>>>> >>
>>>> >>>
>>>> >>>
>>>> >>>> -----Original Message-----
>>>> >>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>>>> >>>> Sent: Wednesday, August 06, 2014 12:59 PM
>>>> >>>> To: dev@cloudstack.apache.org
>>>> >>>> Subject: Re: [VOTE] git workflow
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
>>>> >>>>
>>>> >>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>>>> >>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>> >>>>>
>>>> >>>>>> Agree with you, Rohit. The changes to the git model we use, are
>>>> >>>>>> needed  indeed. But we should address only the problems that CS
>>>> >>>>>>faces,
>>>> >>>>>> and the  main problem - quality control. The proposal should be
>>>> >>>>>> limited just to the  changes that are really needed for the CS,
>>>>and
>>>> >>>>>> that will work with the  current CS model (minor maintenance
>>>> >>>>>>releases
>>>> >>>>>> support is a part of it)
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>> Theoretically you don't really have to change anything other than
>>>> >>>>> merging instead of cherry picking.
>>>> >>>>> That is the main issue from a release perspective.
>>>> >>>>>
>>>> >>>>> But I still think there are good reasons to do so;
>>>> >>>>>
>>>> >>>>> 1) using a well known way of handling code/releases instantly
>>>>tells
>>>> >>>>>new
>>>> >>>>> contributors / committers how we work. add to the fact that there
>>>> >>>>> exists tools to help doing this correctly is a bonus.
>>>> >>>>> 2) having a known stable (atleast in theory) release as master is
>>>> >>>>>good
>>>> >>>>> practice. although not many users will be running from git, i
>>>>still
>>>> >>>>> consider it to be good practice.
>>>> >>>>> 3) there is a huge belief in this thread/discussion that as long
>>>>as
>>>> >>>>> something passes CI / BVT it is considered stable. The fact is
>>>>that
>>>> >>>>>it
>>>> >>>>> is not. Take the recent 4.4 release as a good example, where a
>>>>new
>>>> >>>>> install was not working at all at the point of release. Now, this
>>>>is
>>>> >>>>> more a CI / test coverage issue than git workflow issue, but i
>>>>find
>>>> >>>>>it
>>>> >>>>> weird to use as an argument for not improving the workflow.
>>>> >>>>>
>>>> >>>>> --
>>>> >>>>> Erik
>>>> >>>>
>>>> >>>> I¹m not arguing against keeping master release stable; I advocate
>>>>for
>>>> >>>> it.
>>>> >>>
>>>> >>> +1, we need to take action to make sure master is stable. Frankly
>>>> >>> speaking,
>>>> >>> I don't want to fix the regression on the master, I assume nobody
>>>>want
>>>> >>>to
>>>> >>> do that.
>>>> >>> Here is the list of regression issues(not introduced by myself) I
>>>>fixed
>>>> >>> on master after 4.4:
>>>> >>>
>>>> >>> CLOUDSTACK-7123
>>>> >>> CLOUDSTACK-7110
>>>> >>> CLOUDSTACK-7166
>>>> >>> CLOUDSTACK-7164
>>>> >>> Most of this issues will be caught even by a simulator BVT. I want
>>>>to
>>>> >>> make it clear, that,
>>>> >>> If we don't take action to reduce/eliminate the regression as much
>>>>as
>>>> >>> possible in the future, I will not fix any of this regression
>>>>issues.
>>>> >>> I remember there is discussion about setting up a staging branch,
>>>>run
>>>> >>>BVT
>>>> >>> against it for each commit, what's the conclusion if any? Why so
>>>> >>> difficult to make it happen? Is there anything I can help to make
>>>>it
>>>> >>> happen?
>>>> >>>
>>>> >>>> But we can¹t adopt git workflow way of keeping master branch to be
>>>>a
>>>> >>>> reflection of the latest release branch. It will not work with our
>>>>way
>>>> >>>> of
>>>> >>>> handling maintenance releases for multiple versions of CS - see
>>>> >>>>another
>>>> >>>> thread.
>>>> >>>
>>>> >>>
>>>> >>> +1, I'll -1 on any of proposal, if it doesn't solve problem most of
>>>>us
>>>> >>> are concerning about.
>>>> >>>
>>>> >>>>
>>>> >>>> Instead, master branch should reflect the latest code that passed
>>>>the
>>>> >>>> CI test
>>>> >>>> (the code merged from *develop after CI passes). The release
>>>>branches
>>>> >>>> should be cut from stable master branch - it will ensure that we
>>>>won¹t
>>>> >>>> face
>>>> >>>> last minute blockers as for 4.4, because master IS a stable
>>>>branch.
>>>> >>>> And yes, we should do merges instead of cherry picking.
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>>
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>>
>>
>



-- 
Daan

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Plus if you read the discussion below the article, you will see that
people agree that this model doesn’t work well for the case when the
product support maintenance for older releases, like CS does.

"I think this model does not work for bugfixing in older releases, though.
It messes up the neat ordering.

1. Say we have released Version 1.0.1 and later added features and
released 1.1.0.
2. We discover a bug in 1.0.1 and want to fix it in both version
3. We have to add 1.0.2 after 1.1.0 in master and then directly atfer (or
before) also 1.1.1.”


Thanks,
Alena.

On 8/7/14, 10:19 AM, "Alena Prokharchyk" <Al...@citrix.com>
wrote:

>Not quite. That’s what the article suggests:
>
>"If you want to fix bugs for older releases or do any other develop there,
>you will fork a support branch from the appropriate commit in master (you
>will have all versions ever created there). These branches are just
>started and not intended to be merged back to master nor develop. This is
>usually fine, as fixes to "ancient" releases or features requested by
>customers to be implemented in "ancient" releases can't or should not go
>back into master. If you still think, you want to port a fix to your main
>development line (represented by master and develop), just start a hotfix,
>cherry-pick your changes and finish the hotfix."
>
>
>That doesn’t seem right to me - that NOT ALL the fixes done to 4.2.1/4.3.1
>maintenance releases for example, will go back to master/develop? Plus it
>suggests “cherry-picking” stuff if we decide that some fixes worth being
>back ported. Cherry-picking again? :) Defeats our cherry-pick witch hunt
>purpose. I think ALL fixes done to any forked branch, should make it into
>master via merge.
>
>
>On 8/7/14, 6:39 AM, "Tracy Phillips" <tr...@weberize.com> wrote:
>
>>Alena,
>>
>>Check this out and see if it would resolve your concern regarding
>>maintaining multiple releases
>>
>>http://stackoverflow.com/questions/16562339/git-flow-and-master-with-mult
>>i
>>ple-parallel-release-branches
>>
>>git-flow uses support branches to support releases that are not on
>>master.
>>
>>
>>
>>
>>
>>On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
>>Alena.Prokharchyk@citrix.com> wrote:
>>
>>>
>>>
>>> On 8/6/14, 3:18 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>>
>>> >[top posting, apologies in advance]
>>> >
>>> >I am on vacation, so I will go straight to it :)
>>> >
>>> >This all discussion is not about gitflow specifically, it is about
>>> >modifying our git workflow and our commit practices to something more
>>> >standard that can:
>>> >
>>> >- ultimately help improve quality (in itself it won't but it can help
>>>lay
>>> >a foundation)
>>> >- provide a stable master (it keeps breaking, it has regressions, it
>>> >moves really fast etc..)
>>> >- help cut releases
>>> >
>>> >Any committer has write privileges and can do whatever it wants to the
>>> >repos, so we need to get a nice big consensus on what problems we are
>>> >trying to solve, and how best to get there. So let's not make this a
>>> >debate of yeah or neah gitflow.
>>> >
>>> >A better CI is coming but it's not yet there and we have no ETA. Even
>>> >with a CI infra in place, we will need commit discipline to improve
>>> >quality (covertity, unitests, simulator tests). Changing our git
>>>commit
>>> >practices has no cost (just emails and self discipline), so can we
>>>agree
>>> >to do that first ?
>>> >
>>> >Here are couple high level things that I have in mind ( and I confess
>>>I
>>> >have not read the entire threads on this yet and ti ma conflict with
>>> >gitflow).
>>> >
>>> >-Master: what goes in master is only something that has been put into
>>>a
>>> >release (aside from the maintenance releases fixes maybe...). Master
>>>is
>>> >the base for any release branch (until we get to 4.5, master will
>>>still
>>> >see some high churn to stabilize it, after 4.5 release branch is cut
>>>we
>>> >should enter into a stable master mode).
>>>
>>>
>>> Sebastian, we can’t adopt this particular high level thing - when
>>>master
>>> reflects the latest stable release with the tags for all previous
>>>releases
>>> - because support maintenance releases for multiple CS versions in
>>> parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1 can
>>>be
>>> released. And there is no way to merge them back to master w/o breaking
>>> the branch history.
>>>
>>> The model when master reflects the latest released branch, can be used
>>>for
>>> the systems with rolling upgrades only, no maintenance releases for
>>> previous versions of the software.
>>>
>>> To get more details, please read the latest email exchange (today’s) on
>>> git workflow between me/Rohit and Dave Nalley.
>>>
>>>
>>>
>>> >
>>> >-Release: from the time a release branch is cut, features are only
>>>merged
>>> >by RM. hot fixes are only merged by RM. the RM is responsible for the
>>> >entire release process. Since he defines the scope and is the primary
>>> >person responsible to check BVT for the release branch he should be
>>>able
>>> >to release on-time. Major release gets merged back into master.
>>> >
>>> >-Devs: folks working on features and fixes are responsible to merge
>>>into
>>> >the develop branch and call the RM for a merge into a release branch
>>> >(this may vary with gitflow, where release branch is cut from develop)
>>> >
>>> >Once we have CI, it should run on every branch.
>>> >
>>> >-sebastien
>>> >
>>> >
>>> >On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
>>> ><Al...@citrix.com> wrote:
>>> >
>>> >> Edison, thank you for raising the concern about the BVT/CI. Somebody
>>> >> mentioned earlier that we should separate git workflow
>>>implementation
>>> >>from
>>> >> the CI effort, but I do think we have to do in in conjunction.
>>>Otherwise
>>> >> what is the point in introducing staging/develop branch? If there is
>>>no
>>> >> daily automation run verifying all the code merged from
>>>hotFixes/feature
>>> >> branches (and possibly reverting wrong checkins), we can as well
>>>merge
>>> >>the
>>> >> code directly to master.
>>> >>
>>> >> -Alena.
>>> >>
>>> >> On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
>>> >>
>>> >>>
>>> >>>
>>> >>>> -----Original Message-----
>>> >>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>>> >>>> Sent: Wednesday, August 06, 2014 12:59 PM
>>> >>>> To: dev@cloudstack.apache.org
>>> >>>> Subject: Re: [VOTE] git workflow
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
>>> >>>>
>>> >>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>>> >>>>> Alena.Prokharchyk@citrix.com> wrote:
>>> >>>>>
>>> >>>>>> Agree with you, Rohit. The changes to the git model we use, are
>>> >>>>>> needed  indeed. But we should address only the problems that CS
>>> >>>>>>faces,
>>> >>>>>> and the  main problem - quality control. The proposal should be
>>> >>>>>> limited just to the  changes that are really needed for the CS,
>>>and
>>> >>>>>> that will work with the  current CS model (minor maintenance
>>> >>>>>>releases
>>> >>>>>> support is a part of it)
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>> Theoretically you don't really have to change anything other than
>>> >>>>> merging instead of cherry picking.
>>> >>>>> That is the main issue from a release perspective.
>>> >>>>>
>>> >>>>> But I still think there are good reasons to do so;
>>> >>>>>
>>> >>>>> 1) using a well known way of handling code/releases instantly
>>>tells
>>> >>>>>new
>>> >>>>> contributors / committers how we work. add to the fact that there
>>> >>>>> exists tools to help doing this correctly is a bonus.
>>> >>>>> 2) having a known stable (atleast in theory) release as master is
>>> >>>>>good
>>> >>>>> practice. although not many users will be running from git, i
>>>still
>>> >>>>> consider it to be good practice.
>>> >>>>> 3) there is a huge belief in this thread/discussion that as long
>>>as
>>> >>>>> something passes CI / BVT it is considered stable. The fact is
>>>that
>>> >>>>>it
>>> >>>>> is not. Take the recent 4.4 release as a good example, where a
>>>new
>>> >>>>> install was not working at all at the point of release. Now, this
>>>is
>>> >>>>> more a CI / test coverage issue than git workflow issue, but i
>>>find
>>> >>>>>it
>>> >>>>> weird to use as an argument for not improving the workflow.
>>> >>>>>
>>> >>>>> --
>>> >>>>> Erik
>>> >>>>
>>> >>>> I¹m not arguing against keeping master release stable; I advocate
>>>for
>>> >>>> it.
>>> >>>
>>> >>> +1, we need to take action to make sure master is stable. Frankly
>>> >>> speaking,
>>> >>> I don't want to fix the regression on the master, I assume nobody
>>>want
>>> >>>to
>>> >>> do that.
>>> >>> Here is the list of regression issues(not introduced by myself) I
>>>fixed
>>> >>> on master after 4.4:
>>> >>>
>>> >>> CLOUDSTACK-7123
>>> >>> CLOUDSTACK-7110
>>> >>> CLOUDSTACK-7166
>>> >>> CLOUDSTACK-7164
>>> >>> Most of this issues will be caught even by a simulator BVT. I want
>>>to
>>> >>> make it clear, that,
>>> >>> If we don't take action to reduce/eliminate the regression as much
>>>as
>>> >>> possible in the future, I will not fix any of this regression
>>>issues.
>>> >>> I remember there is discussion about setting up a staging branch,
>>>run
>>> >>>BVT
>>> >>> against it for each commit, what's the conclusion if any? Why so
>>> >>> difficult to make it happen? Is there anything I can help to make
>>>it
>>> >>> happen?
>>> >>>
>>> >>>> But we can¹t adopt git workflow way of keeping master branch to be
>>>a
>>> >>>> reflection of the latest release branch. It will not work with our
>>>way
>>> >>>> of
>>> >>>> handling maintenance releases for multiple versions of CS - see
>>> >>>>another
>>> >>>> thread.
>>> >>>
>>> >>>
>>> >>> +1, I'll -1 on any of proposal, if it doesn't solve problem most of
>>>us
>>> >>> are concerning about.
>>> >>>
>>> >>>>
>>> >>>> Instead, master branch should reflect the latest code that passed
>>>the
>>> >>>> CI test
>>> >>>> (the code merged from *develop after CI passes). The release
>>>branches
>>> >>>> should be cut from stable master branch - it will ensure that we
>>>won¹t
>>> >>>> face
>>> >>>> last minute blockers as for 4.4, because master IS a stable
>>>branch.
>>> >>>> And yes, we should do merges instead of cherry picking.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>>
>>> >>>
>>> >>
>>> >
>>>
>>>
>

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Not quite. That’s what the article suggests:

"If you want to fix bugs for older releases or do any other develop there,
you will fork a support branch from the appropriate commit in master (you
will have all versions ever created there). These branches are just
started and not intended to be merged back to master nor develop. This is
usually fine, as fixes to "ancient" releases or features requested by
customers to be implemented in "ancient" releases can't or should not go
back into master. If you still think, you want to port a fix to your main
development line (represented by master and develop), just start a hotfix,
cherry-pick your changes and finish the hotfix."


That doesn’t seem right to me - that NOT ALL the fixes done to 4.2.1/4.3.1
maintenance releases for example, will go back to master/develop? Plus it
suggests “cherry-picking” stuff if we decide that some fixes worth being
back ported. Cherry-picking again? :) Defeats our cherry-pick witch hunt
purpose. I think ALL fixes done to any forked branch, should make it into
master via merge.


On 8/7/14, 6:39 AM, "Tracy Phillips" <tr...@weberize.com> wrote:

>Alena,
>
>Check this out and see if it would resolve your concern regarding
>maintaining multiple releases
>
>http://stackoverflow.com/questions/16562339/git-flow-and-master-with-multi
>ple-parallel-release-branches
>
>git-flow uses support branches to support releases that are not on master.
>
>
>
>
>
>On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
>Alena.Prokharchyk@citrix.com> wrote:
>
>>
>>
>> On 8/6/14, 3:18 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>
>> >[top posting, apologies in advance]
>> >
>> >I am on vacation, so I will go straight to it :)
>> >
>> >This all discussion is not about gitflow specifically, it is about
>> >modifying our git workflow and our commit practices to something more
>> >standard that can:
>> >
>> >- ultimately help improve quality (in itself it won't but it can help
>>lay
>> >a foundation)
>> >- provide a stable master (it keeps breaking, it has regressions, it
>> >moves really fast etc..)
>> >- help cut releases
>> >
>> >Any committer has write privileges and can do whatever it wants to the
>> >repos, so we need to get a nice big consensus on what problems we are
>> >trying to solve, and how best to get there. So let's not make this a
>> >debate of yeah or neah gitflow.
>> >
>> >A better CI is coming but it's not yet there and we have no ETA. Even
>> >with a CI infra in place, we will need commit discipline to improve
>> >quality (covertity, unitests, simulator tests). Changing our git commit
>> >practices has no cost (just emails and self discipline), so can we
>>agree
>> >to do that first ?
>> >
>> >Here are couple high level things that I have in mind ( and I confess I
>> >have not read the entire threads on this yet and ti ma conflict with
>> >gitflow).
>> >
>> >-Master: what goes in master is only something that has been put into a
>> >release (aside from the maintenance releases fixes maybe...). Master is
>> >the base for any release branch (until we get to 4.5, master will still
>> >see some high churn to stabilize it, after 4.5 release branch is cut we
>> >should enter into a stable master mode).
>>
>>
>> Sebastian, we can’t adopt this particular high level thing - when master
>> reflects the latest stable release with the tags for all previous
>>releases
>> - because support maintenance releases for multiple CS versions in
>> parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1 can
>>be
>> released. And there is no way to merge them back to master w/o breaking
>> the branch history.
>>
>> The model when master reflects the latest released branch, can be used
>>for
>> the systems with rolling upgrades only, no maintenance releases for
>> previous versions of the software.
>>
>> To get more details, please read the latest email exchange (today’s) on
>> git workflow between me/Rohit and Dave Nalley.
>>
>>
>>
>> >
>> >-Release: from the time a release branch is cut, features are only
>>merged
>> >by RM. hot fixes are only merged by RM. the RM is responsible for the
>> >entire release process. Since he defines the scope and is the primary
>> >person responsible to check BVT for the release branch he should be
>>able
>> >to release on-time. Major release gets merged back into master.
>> >
>> >-Devs: folks working on features and fixes are responsible to merge
>>into
>> >the develop branch and call the RM for a merge into a release branch
>> >(this may vary with gitflow, where release branch is cut from develop)
>> >
>> >Once we have CI, it should run on every branch.
>> >
>> >-sebastien
>> >
>> >
>> >On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
>> ><Al...@citrix.com> wrote:
>> >
>> >> Edison, thank you for raising the concern about the BVT/CI. Somebody
>> >> mentioned earlier that we should separate git workflow implementation
>> >>from
>> >> the CI effort, but I do think we have to do in in conjunction.
>>Otherwise
>> >> what is the point in introducing staging/develop branch? If there is
>>no
>> >> daily automation run verifying all the code merged from
>>hotFixes/feature
>> >> branches (and possibly reverting wrong checkins), we can as well
>>merge
>> >>the
>> >> code directly to master.
>> >>
>> >> -Alena.
>> >>
>> >> On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
>> >>
>> >>>
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>> >>>> Sent: Wednesday, August 06, 2014 12:59 PM
>> >>>> To: dev@cloudstack.apache.org
>> >>>> Subject: Re: [VOTE] git workflow
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
>> >>>>
>> >>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>> >>>>> Alena.Prokharchyk@citrix.com> wrote:
>> >>>>>
>> >>>>>> Agree with you, Rohit. The changes to the git model we use, are
>> >>>>>> needed  indeed. But we should address only the problems that CS
>> >>>>>>faces,
>> >>>>>> and the  main problem - quality control. The proposal should be
>> >>>>>> limited just to the  changes that are really needed for the CS,
>>and
>> >>>>>> that will work with the  current CS model (minor maintenance
>> >>>>>>releases
>> >>>>>> support is a part of it)
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>> Theoretically you don't really have to change anything other than
>> >>>>> merging instead of cherry picking.
>> >>>>> That is the main issue from a release perspective.
>> >>>>>
>> >>>>> But I still think there are good reasons to do so;
>> >>>>>
>> >>>>> 1) using a well known way of handling code/releases instantly
>>tells
>> >>>>>new
>> >>>>> contributors / committers how we work. add to the fact that there
>> >>>>> exists tools to help doing this correctly is a bonus.
>> >>>>> 2) having a known stable (atleast in theory) release as master is
>> >>>>>good
>> >>>>> practice. although not many users will be running from git, i
>>still
>> >>>>> consider it to be good practice.
>> >>>>> 3) there is a huge belief in this thread/discussion that as long
>>as
>> >>>>> something passes CI / BVT it is considered stable. The fact is
>>that
>> >>>>>it
>> >>>>> is not. Take the recent 4.4 release as a good example, where a new
>> >>>>> install was not working at all at the point of release. Now, this
>>is
>> >>>>> more a CI / test coverage issue than git workflow issue, but i
>>find
>> >>>>>it
>> >>>>> weird to use as an argument for not improving the workflow.
>> >>>>>
>> >>>>> --
>> >>>>> Erik
>> >>>>
>> >>>> I¹m not arguing against keeping master release stable; I advocate
>>for
>> >>>> it.
>> >>>
>> >>> +1, we need to take action to make sure master is stable. Frankly
>> >>> speaking,
>> >>> I don't want to fix the regression on the master, I assume nobody
>>want
>> >>>to
>> >>> do that.
>> >>> Here is the list of regression issues(not introduced by myself) I
>>fixed
>> >>> on master after 4.4:
>> >>>
>> >>> CLOUDSTACK-7123
>> >>> CLOUDSTACK-7110
>> >>> CLOUDSTACK-7166
>> >>> CLOUDSTACK-7164
>> >>> Most of this issues will be caught even by a simulator BVT. I want
>>to
>> >>> make it clear, that,
>> >>> If we don't take action to reduce/eliminate the regression as much
>>as
>> >>> possible in the future, I will not fix any of this regression
>>issues.
>> >>> I remember there is discussion about setting up a staging branch,
>>run
>> >>>BVT
>> >>> against it for each commit, what's the conclusion if any? Why so
>> >>> difficult to make it happen? Is there anything I can help to make it
>> >>> happen?
>> >>>
>> >>>> But we can¹t adopt git workflow way of keeping master branch to be
>>a
>> >>>> reflection of the latest release branch. It will not work with our
>>way
>> >>>> of
>> >>>> handling maintenance releases for multiple versions of CS - see
>> >>>>another
>> >>>> thread.
>> >>>
>> >>>
>> >>> +1, I'll -1 on any of proposal, if it doesn't solve problem most of
>>us
>> >>> are concerning about.
>> >>>
>> >>>>
>> >>>> Instead, master branch should reflect the latest code that passed
>>the
>> >>>> CI test
>> >>>> (the code merged from *develop after CI passes). The release
>>branches
>> >>>> should be cut from stable master branch - it will ensure that we
>>won¹t
>> >>>> face
>> >>>> last minute blockers as for 4.4, because master IS a stable branch.
>> >>>> And yes, we should do merges instead of cherry picking.
>> >>>>
>> >>>>
>> >>>>
>> >>>>>
>> >>>
>> >>
>> >
>>
>>

Re: [VOTE] git workflow

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

I'm not sure what to think about this discussion any more. But in response
to Sebastien's request for thoughts I was originally very excited about a
git-flow solution because of some very specific things:

* Create a branch for everything. This is amazingly useful for a number of
reasons:

** It supports better CI in the future, specifically build per branch.
Committing directly to a shared branch with CI is not the same thing. I see
great utility in running CI *twice* for every change coming in. Once in
isolation, and again once it is merged in with the rest of the community
work. This enables you to validate that your code is good before subjecting
others to it, and isolates regression testing to just that. It gets much
more difficult to determine if the problem is basic logic in your code or a
regression somewhere else when you don't isolate the changes.

** It encourages people to not force others to deal with something that
isn't completely done or tested, but allows them to still have frequent
commits and share through the central repo. Any time you modify a shared
branch you should be extremely confident that what you have done will only
be a positive impact on the others using that branch. If something breaks,
you are potentially disrupting the work of a large number of other people
in the process. Internally we follow a strict branch and peer review
process for every change. As much as I would like to propose a strict peer
review process for all changes, I have a feeling that it would get even
more pushback than this proposal. I also want to highlight the force part
of my statement. If your change breaks something unrelated to my code, and
now I have to go fix that so that I can get back to what I was originally
doing, I have no choice but to deal with that breakage and am probably very
angry because of that.

* The release process happens in parallel to active development. By using a
release branch to work through QA, testing, bugfixes you enable that work
to happen independent of anything else happening in the code base. I
realize that we already have this process in place for the most part, I
just wanted to highlight that it is something we are already doing in some
form and get to keep doing.

* A stable branch is maintained that only contains code that has been
through a release process. I understand the desire for a nightly process
that merges code from dev to stable, but what is this solving that CI on
all of the branches wouldn't solve? It also assumes that the CI process is
perfect and that all new code has extensive unit/integration tests. Both of
these should be true, but rarely are in the real world and are nowhere
close in today's ACS environment and will take a long time to fix. I also
don't see the momentum to accomplish this in the very near term, so it
feels a bit like we are betting on the the weather a month from now to save
us.

I also realize that git-flow isn't a perfect match for how this community
works, but rolling releases versus maintenance releases doesn't seem major
enough to drop the entire thing. It is fairly easy to have a
maintenance/support branch for older releases that lives on forever once it
is needed. You can also merge any two arbitrary items in git. It might not
be the cleanest merge, but you can merge the maintenance branch into master
once the release of the maintenance branch is done. You could treat it much
like a new release or development branch that comes from master instead of
develop. If this didn't work, long running branches would never work in git.

The TLDR proposal:

* Always make a branch for everything
* Have a branch that is only released code. Not just stable and CI tested,
released.
* Have a development branch where features that haven't been through a
release process can branch from and land when complete
* Use a release branch to move all changes from development to stable to
isolate testing, QA, and release bugfixes
* Create a maintenance branch from the release tag in master once a
maintenance release is needed

I don't care if we call it git-flow, I just liked that it provided a basic
framework from which we could operate and extend.

Thanks,

-Nate


On Thu, Aug 7, 2014 at 8:39 AM, Tracy Phillips <tr...@weberize.com>
wrote:

> Alena,
>
> Check this out and see if it would resolve your concern regarding
> maintaining multiple releases
>
>
> http://stackoverflow.com/questions/16562339/git-flow-and-master-with-multiple-parallel-release-branches
>
> git-flow uses support branches to support releases that are not on master.
>
>
>
>
>
> On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
> >
> >
> > On 8/6/14, 3:18 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
> >
> > >[top posting, apologies in advance]
> > >
> > >I am on vacation, so I will go straight to it :)
> > >
> > >This all discussion is not about gitflow specifically, it is about
> > >modifying our git workflow and our commit practices to something more
> > >standard that can:
> > >
> > >- ultimately help improve quality (in itself it won't but it can help
> lay
> > >a foundation)
> > >- provide a stable master (it keeps breaking, it has regressions, it
> > >moves really fast etc..)
> > >- help cut releases
> > >
> > >Any committer has write privileges and can do whatever it wants to the
> > >repos, so we need to get a nice big consensus on what problems we are
> > >trying to solve, and how best to get there. So let's not make this a
> > >debate of yeah or neah gitflow.
> > >
> > >A better CI is coming but it's not yet there and we have no ETA. Even
> > >with a CI infra in place, we will need commit discipline to improve
> > >quality (covertity, unitests, simulator tests). Changing our git commit
> > >practices has no cost (just emails and self discipline), so can we agree
> > >to do that first ?
> > >
> > >Here are couple high level things that I have in mind ( and I confess I
> > >have not read the entire threads on this yet and ti ma conflict with
> > >gitflow).
> > >
> > >-Master: what goes in master is only something that has been put into a
> > >release (aside from the maintenance releases fixes maybe...). Master is
> > >the base for any release branch (until we get to 4.5, master will still
> > >see some high churn to stabilize it, after 4.5 release branch is cut we
> > >should enter into a stable master mode).
> >
> >
> > Sebastian, we can’t adopt this particular high level thing - when master
> > reflects the latest stable release with the tags for all previous
> releases
> > - because support maintenance releases for multiple CS versions in
> > parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1 can
> be
> > released. And there is no way to merge them back to master w/o breaking
> > the branch history.
> >
> > The model when master reflects the latest released branch, can be used
> for
> > the systems with rolling upgrades only, no maintenance releases for
> > previous versions of the software.
> >
> > To get more details, please read the latest email exchange (today’s) on
> > git workflow between me/Rohit and Dave Nalley.
> >
> >
> >
> > >
> > >-Release: from the time a release branch is cut, features are only
> merged
> > >by RM. hot fixes are only merged by RM. the RM is responsible for the
> > >entire release process. Since he defines the scope and is the primary
> > >person responsible to check BVT for the release branch he should be able
> > >to release on-time. Major release gets merged back into master.
> > >
> > >-Devs: folks working on features and fixes are responsible to merge into
> > >the develop branch and call the RM for a merge into a release branch
> > >(this may vary with gitflow, where release branch is cut from develop)
> > >
> > >Once we have CI, it should run on every branch.
> > >
> > >-sebastien
> > >
> > >
> > >On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
> > ><Al...@citrix.com> wrote:
> > >
> > >> Edison, thank you for raising the concern about the BVT/CI. Somebody
> > >> mentioned earlier that we should separate git workflow implementation
> > >>from
> > >> the CI effort, but I do think we have to do in in conjunction.
> Otherwise
> > >> what is the point in introducing staging/develop branch? If there is
> no
> > >> daily automation run verifying all the code merged from
> hotFixes/feature
> > >> branches (and possibly reverting wrong checkins), we can as well merge
> > >>the
> > >> code directly to master.
> > >>
> > >> -Alena.
> > >>
> > >> On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
> > >>
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> > >>>> Sent: Wednesday, August 06, 2014 12:59 PM
> > >>>> To: dev@cloudstack.apache.org
> > >>>> Subject: Re: [VOTE] git workflow
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
> > >>>>
> > >>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
> > >>>>> Alena.Prokharchyk@citrix.com> wrote:
> > >>>>>
> > >>>>>> Agree with you, Rohit. The changes to the git model we use, are
> > >>>>>> needed  indeed. But we should address only the problems that CS
> > >>>>>>faces,
> > >>>>>> and the  main problem - quality control. The proposal should be
> > >>>>>> limited just to the  changes that are really needed for the CS,
> and
> > >>>>>> that will work with the  current CS model (minor maintenance
> > >>>>>>releases
> > >>>>>> support is a part of it)
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>> Theoretically you don't really have to change anything other than
> > >>>>> merging instead of cherry picking.
> > >>>>> That is the main issue from a release perspective.
> > >>>>>
> > >>>>> But I still think there are good reasons to do so;
> > >>>>>
> > >>>>> 1) using a well known way of handling code/releases instantly tells
> > >>>>>new
> > >>>>> contributors / committers how we work. add to the fact that there
> > >>>>> exists tools to help doing this correctly is a bonus.
> > >>>>> 2) having a known stable (atleast in theory) release as master is
> > >>>>>good
> > >>>>> practice. although not many users will be running from git, i still
> > >>>>> consider it to be good practice.
> > >>>>> 3) there is a huge belief in this thread/discussion that as long as
> > >>>>> something passes CI / BVT it is considered stable. The fact is that
> > >>>>>it
> > >>>>> is not. Take the recent 4.4 release as a good example, where a new
> > >>>>> install was not working at all at the point of release. Now, this
> is
> > >>>>> more a CI / test coverage issue than git workflow issue, but i find
> > >>>>>it
> > >>>>> weird to use as an argument for not improving the workflow.
> > >>>>>
> > >>>>> --
> > >>>>> Erik
> > >>>>
> > >>>> I¹m not arguing against keeping master release stable; I advocate
> for
> > >>>> it.
> > >>>
> > >>> +1, we need to take action to make sure master is stable. Frankly
> > >>> speaking,
> > >>> I don't want to fix the regression on the master, I assume nobody
> want
> > >>>to
> > >>> do that.
> > >>> Here is the list of regression issues(not introduced by myself) I
> fixed
> > >>> on master after 4.4:
> > >>>
> > >>> CLOUDSTACK-7123
> > >>> CLOUDSTACK-7110
> > >>> CLOUDSTACK-7166
> > >>> CLOUDSTACK-7164
> > >>> Most of this issues will be caught even by a simulator BVT. I want to
> > >>> make it clear, that,
> > >>> If we don't take action to reduce/eliminate the regression as much as
> > >>> possible in the future, I will not fix any of this regression issues.
> > >>> I remember there is discussion about setting up a staging branch, run
> > >>>BVT
> > >>> against it for each commit, what's the conclusion if any? Why so
> > >>> difficult to make it happen? Is there anything I can help to make it
> > >>> happen?
> > >>>
> > >>>> But we can¹t adopt git workflow way of keeping master branch to be a
> > >>>> reflection of the latest release branch. It will not work with our
> way
> > >>>> of
> > >>>> handling maintenance releases for multiple versions of CS - see
> > >>>>another
> > >>>> thread.
> > >>>
> > >>>
> > >>> +1, I'll -1 on any of proposal, if it doesn't solve problem most of
> us
> > >>> are concerning about.
> > >>>
> > >>>>
> > >>>> Instead, master branch should reflect the latest code that passed
> the
> > >>>> CI test
> > >>>> (the code merged from *develop after CI passes). The release
> branches
> > >>>> should be cut from stable master branch - it will ensure that we
> won¹t
> > >>>> face
> > >>>> last minute blockers as for 4.4, because master IS a stable branch.
> > >>>> And yes, we should do merges instead of cherry picking.
> > >>>>
> > >>>>
> > >>>>
> > >>>>>
> > >>>
> > >>
> > >
> >
> >
>



-- 


*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] git workflow

[Tracy Phillips <tr...@weberize.com>]

Alena,

Check this out and see if it would resolve your concern regarding
maintaining multiple releases

http://stackoverflow.com/questions/16562339/git-flow-and-master-with-multiple-parallel-release-branches

git-flow uses support branches to support releases that are not on master.





On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

>
>
> On 8/6/14, 3:18 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>
> >[top posting, apologies in advance]
> >
> >I am on vacation, so I will go straight to it :)
> >
> >This all discussion is not about gitflow specifically, it is about
> >modifying our git workflow and our commit practices to something more
> >standard that can:
> >
> >- ultimately help improve quality (in itself it won't but it can help lay
> >a foundation)
> >- provide a stable master (it keeps breaking, it has regressions, it
> >moves really fast etc..)
> >- help cut releases
> >
> >Any committer has write privileges and can do whatever it wants to the
> >repos, so we need to get a nice big consensus on what problems we are
> >trying to solve, and how best to get there. So let's not make this a
> >debate of yeah or neah gitflow.
> >
> >A better CI is coming but it's not yet there and we have no ETA. Even
> >with a CI infra in place, we will need commit discipline to improve
> >quality (covertity, unitests, simulator tests). Changing our git commit
> >practices has no cost (just emails and self discipline), so can we agree
> >to do that first ?
> >
> >Here are couple high level things that I have in mind ( and I confess I
> >have not read the entire threads on this yet and ti ma conflict with
> >gitflow).
> >
> >-Master: what goes in master is only something that has been put into a
> >release (aside from the maintenance releases fixes maybe...). Master is
> >the base for any release branch (until we get to 4.5, master will still
> >see some high churn to stabilize it, after 4.5 release branch is cut we
> >should enter into a stable master mode).
>
>
> Sebastian, we can’t adopt this particular high level thing - when master
> reflects the latest stable release with the tags for all previous releases
> - because support maintenance releases for multiple CS versions in
> parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1 can be
> released. And there is no way to merge them back to master w/o breaking
> the branch history.
>
> The model when master reflects the latest released branch, can be used for
> the systems with rolling upgrades only, no maintenance releases for
> previous versions of the software.
>
> To get more details, please read the latest email exchange (today’s) on
> git workflow between me/Rohit and Dave Nalley.
>
>
>
> >
> >-Release: from the time a release branch is cut, features are only merged
> >by RM. hot fixes are only merged by RM. the RM is responsible for the
> >entire release process. Since he defines the scope and is the primary
> >person responsible to check BVT for the release branch he should be able
> >to release on-time. Major release gets merged back into master.
> >
> >-Devs: folks working on features and fixes are responsible to merge into
> >the develop branch and call the RM for a merge into a release branch
> >(this may vary with gitflow, where release branch is cut from develop)
> >
> >Once we have CI, it should run on every branch.
> >
> >-sebastien
> >
> >
> >On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
> ><Al...@citrix.com> wrote:
> >
> >> Edison, thank you for raising the concern about the BVT/CI. Somebody
> >> mentioned earlier that we should separate git workflow implementation
> >>from
> >> the CI effort, but I do think we have to do in in conjunction. Otherwise
> >> what is the point in introducing staging/develop branch? If there is no
> >> daily automation run verifying all the code merged from hotFixes/feature
> >> branches (and possibly reverting wrong checkins), we can as well merge
> >>the
> >> code directly to master.
> >>
> >> -Alena.
> >>
> >> On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
> >>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> >>>> Sent: Wednesday, August 06, 2014 12:59 PM
> >>>> To: dev@cloudstack.apache.org
> >>>> Subject: Re: [VOTE] git workflow
> >>>>
> >>>>
> >>>>
> >>>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
> >>>>
> >>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
> >>>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>>
> >>>>>> Agree with you, Rohit. The changes to the git model we use, are
> >>>>>> needed  indeed. But we should address only the problems that CS
> >>>>>>faces,
> >>>>>> and the  main problem - quality control. The proposal should be
> >>>>>> limited just to the  changes that are really needed for the CS, and
> >>>>>> that will work with the  current CS model (minor maintenance
> >>>>>>releases
> >>>>>> support is a part of it)
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> Theoretically you don't really have to change anything other than
> >>>>> merging instead of cherry picking.
> >>>>> That is the main issue from a release perspective.
> >>>>>
> >>>>> But I still think there are good reasons to do so;
> >>>>>
> >>>>> 1) using a well known way of handling code/releases instantly tells
> >>>>>new
> >>>>> contributors / committers how we work. add to the fact that there
> >>>>> exists tools to help doing this correctly is a bonus.
> >>>>> 2) having a known stable (atleast in theory) release as master is
> >>>>>good
> >>>>> practice. although not many users will be running from git, i still
> >>>>> consider it to be good practice.
> >>>>> 3) there is a huge belief in this thread/discussion that as long as
> >>>>> something passes CI / BVT it is considered stable. The fact is that
> >>>>>it
> >>>>> is not. Take the recent 4.4 release as a good example, where a new
> >>>>> install was not working at all at the point of release. Now, this is
> >>>>> more a CI / test coverage issue than git workflow issue, but i find
> >>>>>it
> >>>>> weird to use as an argument for not improving the workflow.
> >>>>>
> >>>>> --
> >>>>> Erik
> >>>>
> >>>> I¹m not arguing against keeping master release stable; I advocate for
> >>>> it.
> >>>
> >>> +1, we need to take action to make sure master is stable. Frankly
> >>> speaking,
> >>> I don't want to fix the regression on the master, I assume nobody want
> >>>to
> >>> do that.
> >>> Here is the list of regression issues(not introduced by myself) I fixed
> >>> on master after 4.4:
> >>>
> >>> CLOUDSTACK-7123
> >>> CLOUDSTACK-7110
> >>> CLOUDSTACK-7166
> >>> CLOUDSTACK-7164
> >>> Most of this issues will be caught even by a simulator BVT. I want to
> >>> make it clear, that,
> >>> If we don't take action to reduce/eliminate the regression as much as
> >>> possible in the future, I will not fix any of this regression issues.
> >>> I remember there is discussion about setting up a staging branch, run
> >>>BVT
> >>> against it for each commit, what's the conclusion if any? Why so
> >>> difficult to make it happen? Is there anything I can help to make it
> >>> happen?
> >>>
> >>>> But we can¹t adopt git workflow way of keeping master branch to be a
> >>>> reflection of the latest release branch. It will not work with our way
> >>>> of
> >>>> handling maintenance releases for multiple versions of CS - see
> >>>>another
> >>>> thread.
> >>>
> >>>
> >>> +1, I'll -1 on any of proposal, if it doesn't solve problem most of us
> >>> are concerning about.
> >>>
> >>>>
> >>>> Instead, master branch should reflect the latest code that passed the
> >>>> CI test
> >>>> (the code merged from *develop after CI passes). The release branches
> >>>> should be cut from stable master branch - it will ensure that we won¹t
> >>>> face
> >>>> last minute blockers as for 4.4, because master IS a stable branch.
> >>>> And yes, we should do merges instead of cherry picking.
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>
> >>
> >
>
>

Re: [VOTE] git workflow

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

7. aug. 2014 00:28 skrev "Alena Prokharchyk" <Al...@citrix.com>
følgende:
>
>
>
> On 8/6/14, 3:18 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>
> >[top posting, apologies in advance]
> >
> >I am on vacation, so I will go straight to it :)
> >
> >This all discussion is not about gitflow specifically, it is about
> >modifying our git workflow and our commit practices to something more
> >standard that can:
> >
> >- ultimately help improve quality (in itself it won't but it can help lay
> >a foundation)
> >- provide a stable master (it keeps breaking, it has regressions, it
> >moves really fast etc..)
> >- help cut releases
> >
> >Any committer has write privileges and can do whatever it wants to the
> >repos, so we need to get a nice big consensus on what problems we are
> >trying to solve, and how best to get there. So let's not make this a
> >debate of yeah or neah gitflow.
> >
> >A better CI is coming but it's not yet there and we have no ETA. Even
> >with a CI infra in place, we will need commit discipline to improve
> >quality (covertity, unitests, simulator tests). Changing our git commit
> >practices has no cost (just emails and self discipline), so can we agree
> >to do that first ?
> >
> >Here are couple high level things that I have in mind ( and I confess I
> >have not read the entire threads on this yet and ti ma conflict with
> >gitflow).
> >
> >-Master: what goes in master is only something that has been put into a
> >release (aside from the maintenance releases fixes maybe...). Master is
> >the base for any release branch (until we get to 4.5, master will still
> >see some high churn to stabilize it, after 4.5 release branch is cut we
> >should enter into a stable master mode).
>
>
> Sebastian, we can’t adopt this particular high level thing - when master
> reflects the latest stable release with the tags for all previous releases
> - because support maintenance releases for multiple CS versions in
> parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1 can be
> released. And there is no way to merge them back to master w/o breaking
> the branch history.
>

Gitflow supports this, see one of my other responses for how, but only new
major versions (ie 4.4.0, 4.5.0, 4.6.0 etc.) goes to master. Support
(maintenance if you prefer) releases live their life in their own branches.

> The model when master reflects the latest released branch, can be used for
> the systems with rolling upgrades only, no maintenance releases for
> previous versions of the software.
>
> To get more details, please read the latest email exchange (today’s) on
> git workflow between me/Rohit and Dave Nalley.
>
>
>
> >
> >-Release: from the time a release branch is cut, features are only merged
> >by RM. hot fixes are only merged by RM. the RM is responsible for the
> >entire release process. Since he defines the scope and is the primary
> >person responsible to check BVT for the release branch he should be able
> >to release on-time. Major release gets merged back into master.
> >
> >-Devs: folks working on features and fixes are responsible to merge into
> >the develop branch and call the RM for a merge into a release branch
> >(this may vary with gitflow, where release branch is cut from develop)
> >
> >Once we have CI, it should run on every branch.
> >
> >-sebastien
> >
> >
> >On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
> ><Al...@citrix.com> wrote:
> >
> >> Edison, thank you for raising the concern about the BVT/CI. Somebody
> >> mentioned earlier that we should separate git workflow implementation
> >>from
> >> the CI effort, but I do think we have to do in in conjunction.
Otherwise
> >> what is the point in introducing staging/develop branch? If there is no
> >> daily automation run verifying all the code merged from
hotFixes/feature
> >> branches (and possibly reverting wrong checkins), we can as well merge
> >>the
> >> code directly to master.
> >>
> >> -Alena.
> >>
> >> On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
> >>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> >>>> Sent: Wednesday, August 06, 2014 12:59 PM
> >>>> To: dev@cloudstack.apache.org
> >>>> Subject: Re: [VOTE] git workflow
> >>>>
> >>>>
> >>>>
> >>>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
> >>>>
> >>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
> >>>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>>
> >>>>>> Agree with you, Rohit. The changes to the git model we use, are
> >>>>>> needed  indeed. But we should address only the problems that CS
> >>>>>>faces,
> >>>>>> and the  main problem - quality control. The proposal should be
> >>>>>> limited just to the  changes that are really needed for the CS, and
> >>>>>> that will work with the  current CS model (minor maintenance
> >>>>>>releases
> >>>>>> support is a part of it)
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> Theoretically you don't really have to change anything other than
> >>>>> merging instead of cherry picking.
> >>>>> That is the main issue from a release perspective.
> >>>>>
> >>>>> But I still think there are good reasons to do so;
> >>>>>
> >>>>> 1) using a well known way of handling code/releases instantly tells
> >>>>>new
> >>>>> contributors / committers how we work. add to the fact that there
> >>>>> exists tools to help doing this correctly is a bonus.
> >>>>> 2) having a known stable (atleast in theory) release as master is
> >>>>>good
> >>>>> practice. although not many users will be running from git, i still
> >>>>> consider it to be good practice.
> >>>>> 3) there is a huge belief in this thread/discussion that as long as
> >>>>> something passes CI / BVT it is considered stable. The fact is that
> >>>>>it
> >>>>> is not. Take the recent 4.4 release as a good example, where a new
> >>>>> install was not working at all at the point of release. Now, this is
> >>>>> more a CI / test coverage issue than git workflow issue, but i find
> >>>>>it
> >>>>> weird to use as an argument for not improving the workflow.
> >>>>>
> >>>>> --
> >>>>> Erik
> >>>>
> >>>> I¹m not arguing against keeping master release stable; I advocate for
> >>>> it.
> >>>
> >>> +1, we need to take action to make sure master is stable. Frankly
> >>> speaking,
> >>> I don't want to fix the regression on the master, I assume nobody want
> >>>to
> >>> do that.
> >>> Here is the list of regression issues(not introduced by myself) I
fixed
> >>> on master after 4.4:
> >>>
> >>> CLOUDSTACK-7123
> >>> CLOUDSTACK-7110
> >>> CLOUDSTACK-7166
> >>> CLOUDSTACK-7164
> >>> Most of this issues will be caught even by a simulator BVT. I want to
> >>> make it clear, that,
> >>> If we don't take action to reduce/eliminate the regression as much as
> >>> possible in the future, I will not fix any of this regression issues.
> >>> I remember there is discussion about setting up a staging branch, run
> >>>BVT
> >>> against it for each commit, what's the conclusion if any? Why so
> >>> difficult to make it happen? Is there anything I can help to make it
> >>> happen?
> >>>
> >>>> But we can¹t adopt git workflow way of keeping master branch to be a
> >>>> reflection of the latest release branch. It will not work with our
way
> >>>> of
> >>>> handling maintenance releases for multiple versions of CS - see
> >>>>another
> >>>> thread.
> >>>
> >>>
> >>> +1, I'll -1 on any of proposal, if it doesn't solve problem most of us
> >>> are concerning about.
> >>>
> >>>>
> >>>> Instead, master branch should reflect the latest code that passed the
> >>>> CI test
> >>>> (the code merged from *develop after CI passes). The release branches
> >>>> should be cut from stable master branch - it will ensure that we
won¹t
> >>>> face
> >>>> last minute blockers as for 4.4, because master IS a stable branch.
> >>>> And yes, we should do merges instead of cherry picking.
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>
> >>
> >
>

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

On 8/6/14, 3:18 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:

>[top posting, apologies in advance]
>
>I am on vacation, so I will go straight to it :)
>
>This all discussion is not about gitflow specifically, it is about
>modifying our git workflow and our commit practices to something more
>standard that can:
>
>- ultimately help improve quality (in itself it won't but it can help lay
>a foundation)
>- provide a stable master (it keeps breaking, it has regressions, it
>moves really fast etc..)
>- help cut releases
>
>Any committer has write privileges and can do whatever it wants to the
>repos, so we need to get a nice big consensus on what problems we are
>trying to solve, and how best to get there. So let's not make this a
>debate of yeah or neah gitflow.
>
>A better CI is coming but it's not yet there and we have no ETA. Even
>with a CI infra in place, we will need commit discipline to improve
>quality (covertity, unitests, simulator tests). Changing our git commit
>practices has no cost (just emails and self discipline), so can we agree
>to do that first ?
>
>Here are couple high level things that I have in mind ( and I confess I
>have not read the entire threads on this yet and ti ma conflict with
>gitflow).
>
>-Master: what goes in master is only something that has been put into a
>release (aside from the maintenance releases fixes maybe...). Master is
>the base for any release branch (until we get to 4.5, master will still
>see some high churn to stabilize it, after 4.5 release branch is cut we
>should enter into a stable master mode).


Sebastian, we can’t adopt this particular high level thing - when master
reflects the latest stable release with the tags for all previous releases
- because support maintenance releases for multiple CS versions in
parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1 can be
released. And there is no way to merge them back to master w/o breaking
the branch history.

The model when master reflects the latest released branch, can be used for
the systems with rolling upgrades only, no maintenance releases for
previous versions of the software.

To get more details, please read the latest email exchange (today’s) on
git workflow between me/Rohit and Dave Nalley.



>
>-Release: from the time a release branch is cut, features are only merged
>by RM. hot fixes are only merged by RM. the RM is responsible for the
>entire release process. Since he defines the scope and is the primary
>person responsible to check BVT for the release branch he should be able
>to release on-time. Major release gets merged back into master.
>
>-Devs: folks working on features and fixes are responsible to merge into
>the develop branch and call the RM for a merge into a release branch
>(this may vary with gitflow, where release branch is cut from develop)
>
>Once we have CI, it should run on every branch.
>
>-sebastien
>
>
>On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
><Al...@citrix.com> wrote:
>
>> Edison, thank you for raising the concern about the BVT/CI. Somebody
>> mentioned earlier that we should separate git workflow implementation
>>from
>> the CI effort, but I do think we have to do in in conjunction. Otherwise
>> what is the point in introducing staging/develop branch? If there is no
>> daily automation run verifying all the code merged from hotFixes/feature
>> branches (and possibly reverting wrong checkins), we can as well merge
>>the
>> code directly to master.
>> 
>> -Alena.
>> 
>> On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>>>> Sent: Wednesday, August 06, 2014 12:59 PM
>>>> To: dev@cloudstack.apache.org
>>>> Subject: Re: [VOTE] git workflow
>>>> 
>>>> 
>>>> 
>>>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
>>>> 
>>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>>> 
>>>>>> Agree with you, Rohit. The changes to the git model we use, are
>>>>>> needed  indeed. But we should address only the problems that CS
>>>>>>faces,
>>>>>> and the  main problem - quality control. The proposal should be
>>>>>> limited just to the  changes that are really needed for the CS, and
>>>>>> that will work with the  current CS model (minor maintenance
>>>>>>releases
>>>>>> support is a part of it)
>>>>>> 
>>>>>> 
>>>>> 
>>>>> Theoretically you don't really have to change anything other than
>>>>> merging instead of cherry picking.
>>>>> That is the main issue from a release perspective.
>>>>> 
>>>>> But I still think there are good reasons to do so;
>>>>> 
>>>>> 1) using a well known way of handling code/releases instantly tells
>>>>>new
>>>>> contributors / committers how we work. add to the fact that there
>>>>> exists tools to help doing this correctly is a bonus.
>>>>> 2) having a known stable (atleast in theory) release as master is
>>>>>good
>>>>> practice. although not many users will be running from git, i still
>>>>> consider it to be good practice.
>>>>> 3) there is a huge belief in this thread/discussion that as long as
>>>>> something passes CI / BVT it is considered stable. The fact is that
>>>>>it
>>>>> is not. Take the recent 4.4 release as a good example, where a new
>>>>> install was not working at all at the point of release. Now, this is
>>>>> more a CI / test coverage issue than git workflow issue, but i find
>>>>>it
>>>>> weird to use as an argument for not improving the workflow.
>>>>> 
>>>>> --
>>>>> Erik
>>>> 
>>>> I¹m not arguing against keeping master release stable; I advocate for
>>>> it.
>>> 
>>> +1, we need to take action to make sure master is stable. Frankly
>>> speaking, 
>>> I don't want to fix the regression on the master, I assume nobody want
>>>to
>>> do that.
>>> Here is the list of regression issues(not introduced by myself) I fixed
>>> on master after 4.4:
>>> 
>>> CLOUDSTACK-7123
>>> CLOUDSTACK-7110
>>> CLOUDSTACK-7166
>>> CLOUDSTACK-7164
>>> Most of this issues will be caught even by a simulator BVT. I want to
>>> make it clear, that,
>>> If we don't take action to reduce/eliminate the regression as much as
>>> possible in the future, I will not fix any of this regression issues.
>>> I remember there is discussion about setting up a staging branch, run
>>>BVT
>>> against it for each commit, what's the conclusion if any? Why so
>>> difficult to make it happen? Is there anything I can help to make it
>>> happen?
>>> 
>>>> But we can¹t adopt git workflow way of keeping master branch to be a
>>>> reflection of the latest release branch. It will not work with our way
>>>> of
>>>> handling maintenance releases for multiple versions of CS - see
>>>>another
>>>> thread.
>>> 
>>> 
>>> +1, I'll -1 on any of proposal, if it doesn't solve problem most of us
>>> are concerning about.
>>> 
>>>> 
>>>> Instead, master branch should reflect the latest code that passed the
>>>> CI test
>>>> (the code merged from *develop after CI passes). The release branches
>>>> should be cut from stable master branch - it will ensure that we won¹t
>>>> face
>>>> last minute blockers as for 4.4, because master IS a stable branch.
>>>> And yes, we should do merges instead of cherry picking.
>>>> 
>>>> 
>>>> 
>>>>> 
>>> 
>> 
>

RE: [VOTE] git workflow

[Animesh Chaturvedi <an...@citrix.com>]

> -----Original Message-----
> From: Sebastien Goasguen [mailto:runseb@gmail.com]
> Sent: Wednesday, August 06, 2014 3:19 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] git workflow
> 
> [top posting, apologies in advance]
> 
> I am on vacation, so I will go straight to it :)
> 
> This all discussion is not about gitflow specifically, it is about modifying our
> git workflow and our commit practices to something more standard that
> can:
> 
> - ultimately help improve quality (in itself it won't but it can help lay a
> foundation)
> - provide a stable master (it keeps breaking, it has regressions, it moves
> really fast etc..)
> - help cut releases
> 
> Any committer has write privileges and can do whatever it wants to the
> repos, so we need to get a nice big consensus on what problems we are
> trying to solve, and how best to get there. So let's not make this a debate of
> yeah or neah gitflow.
> 
> A better CI is coming but it's not yet there and we have no ETA. Even with a
> CI infra in place, we will need commit discipline to improve quality
> (covertity, unitests, simulator tests). Changing our git commit practices has
> no cost (just emails and self discipline), so can we agree to do that first ?
> 
> Here are couple high level things that I have in mind ( and I confess I have
> not read the entire threads on this yet and ti ma conflict with gitflow).
> 
> -Master: what goes in master is only something that has been put into a
> release (aside from the maintenance releases fixes maybe...). Master is the
> base for any release branch (until we get to 4.5, master will still see some
> high churn to stabilize it, after 4.5 release branch is cut we should enter into
> a stable master mode).
> 
> -Release: from the time a release branch is cut, features are only merged by
> RM. 
[Animesh] Features have to be merged into develop branch before the feature freeze date in order to make into release branch. This is not done by RM but the feature developer.  Release branch should already have features that made it by the feature freeze date


hot fixes are only merged by RM. the RM is responsible for the entire
> release process. Since he defines the scope and is the primary person
> responsible to check BVT for the release branch he should be able to release
> on-time. Major release gets merged back into master.
> 
> -Devs: folks working on features and fixes are responsible to merge into the
> develop branch and call the RM for a merge into a release branch (this may
> vary with gitflow, where release branch is cut from develop)
[Animesh] I want to be clear on timing for this otherwise RM cannot scale and will drown in these requests. When Chip and I were running releases we started cherry-picks when we got closer to RC. I did not see cherry-pick as a big pain for 4.2 and 4.3. 
> 
> Once we have CI, it should run on every branch.
> 
> -sebastien
> 
> 
> On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
> <Al...@citrix.com> wrote:
> 
> > Edison, thank you for raising the concern about the BVT/CI. Somebody
> > mentioned earlier that we should separate git workflow implementation
> > from the CI effort, but I do think we have to do in in conjunction.
> > Otherwise what is the point in introducing staging/develop branch? If
> > there is no daily automation run verifying all the code merged from
> > hotFixes/feature branches (and possibly reverting wrong checkins), we
> > can as well merge the code directly to master.
> >
> > -Alena.
> >
> > On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> >>> Sent: Wednesday, August 06, 2014 12:59 PM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: Re: [VOTE] git workflow
> >>>
> >>>
> >>>
> >>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
> >>>
> >>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
> >>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>
> >>>>> Agree with you, Rohit. The changes to the git model we use, are
> >>>>> needed  indeed. But we should address only the problems that CS
> >>>>> faces, and the  main problem - quality control. The proposal
> >>>>> should be limited just to the  changes that are really needed for
> >>>>> the CS, and that will work with the  current CS model (minor
> >>>>> maintenance releases support is a part of it)
> >>>>>
> >>>>>
> >>>>
> >>>> Theoretically you don't really have to change anything other than
> >>>> merging instead of cherry picking.
> >>>> That is the main issue from a release perspective.
> >>>>
> >>>> But I still think there are good reasons to do so;
> >>>>
> >>>> 1) using a well known way of handling code/releases instantly tells
> >>>> new contributors / committers how we work. add to the fact that
> >>>> there exists tools to help doing this correctly is a bonus.
> >>>> 2) having a known stable (atleast in theory) release as master is
> >>>> good practice. although not many users will be running from git, i
> >>>> still consider it to be good practice.
> >>>> 3) there is a huge belief in this thread/discussion that as long as
> >>>> something passes CI / BVT it is considered stable. The fact is that
> >>>> it is not. Take the recent 4.4 release as a good example, where a
> >>>> new install was not working at all at the point of release. Now,
> >>>> this is more a CI / test coverage issue than git workflow issue,
> >>>> but i find it weird to use as an argument for not improving the
> workflow.
> >>>>
> >>>> --
> >>>> Erik
> >>>
> >>> I¹m not arguing against keeping master release stable; I advocate
> >>> for it.
> >>
> >> +1, we need to take action to make sure master is stable. Frankly
> >> speaking,
> >> I don't want to fix the regression on the master, I assume nobody
> >> want to do that.
> >> Here is the list of regression issues(not introduced by myself) I
> >> fixed on master after 4.4:
> >>
> >> CLOUDSTACK-7123
> >> CLOUDSTACK-7110
> >> CLOUDSTACK-7166
> >> CLOUDSTACK-7164
> >> Most of this issues will be caught even by a simulator BVT. I want to
> >> make it clear, that, If we don't take action to reduce/eliminate the
> >> regression as much as possible in the future, I will not fix any of
> >> this regression issues.
> >> I remember there is discussion about setting up a staging branch, run
> >> BVT against it for each commit, what's the conclusion if any? Why so
> >> difficult to make it happen? Is there anything I can help to make it
> >> happen?
> >>
> >>> But we can¹t adopt git workflow way of keeping master branch to be a
> >>> reflection of the latest release branch. It will not work with our
> >>> way of handling maintenance releases for multiple versions of CS -
> >>> see another thread.
> >>
> >>
> >> +1, I'll -1 on any of proposal, if it doesn't solve problem most of
> >> +us
> >> are concerning about.
> >>
> >>>
> >>> Instead, master branch should reflect the latest code that passed
> >>> the CI test (the code merged from *develop after CI passes). The
> >>> release branches should be cut from stable master branch - it will
> >>> ensure that we won¹t face last minute blockers as for 4.4, because
> >>> master IS a stable branch.
> >>> And yes, we should do merges instead of cherry picking.
> >>>
> >>>
> >>>
> >>>>
> >>
> >

Re: [VOTE] git workflow

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

[top posting, apologies in advance]

I am on vacation, so I will go straight to it :)

This all discussion is not about gitflow specifically, it is about modifying our git workflow and our commit practices to something more standard that can:

- ultimately help improve quality (in itself it won't but it can help lay a foundation)
- provide a stable master (it keeps breaking, it has regressions, it moves really fast etc..)
- help cut releases

Any committer has write privileges and can do whatever it wants to the repos, so we need to get a nice big consensus on what problems we are trying to solve, and how best to get there. So let's not make this a debate of yeah or neah gitflow.

A better CI is coming but it's not yet there and we have no ETA. Even with a CI infra in place, we will need commit discipline to improve quality (covertity, unitests, simulator tests). Changing our git commit practices has no cost (just emails and self discipline), so can we agree to do that first ?

Here are couple high level things that I have in mind ( and I confess I have not read the entire threads on this yet and ti ma conflict with gitflow).

-Master: what goes in master is only something that has been put into a release (aside from the maintenance releases fixes maybe...). Master is the base for any release branch (until we get to 4.5, master will still see some high churn to stabilize it, after 4.5 release branch is cut we should enter into a stable master mode).

-Release: from the time a release branch is cut, features are only merged by RM. hot fixes are only merged by RM. the RM is responsible for the entire release process. Since he defines the scope and is the primary person responsible to check BVT for the release branch he should be able to release on-time. Major release gets merged back into master.

-Devs: folks working on features and fixes are responsible to merge into the develop branch and call the RM for a merge into a release branch (this may vary with gitflow, where release branch is cut from develop)

Once we have CI, it should run on every branch.

-sebastien


On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk <Al...@citrix.com> wrote:

> Edison, thank you for raising the concern about the BVT/CI. Somebody
> mentioned earlier that we should separate git workflow implementation from
> the CI effort, but I do think we have to do in in conjunction. Otherwise
> what is the point in introducing staging/develop branch? If there is no
> daily automation run verifying all the code merged from hotFixes/feature
> branches (and possibly reverting wrong checkins), we can as well merge the
> code directly to master.
> 
> -Alena.
> 
> On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
> 
>> 
>> 
>>> -----Original Message-----
>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>>> Sent: Wednesday, August 06, 2014 12:59 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [VOTE] git workflow
>>> 
>>> 
>>> 
>>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
>>> 
>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>> 
>>>>> Agree with you, Rohit. The changes to the git model we use, are
>>>>> needed  indeed. But we should address only the problems that CS faces,
>>>>> and the  main problem - quality control. The proposal should be
>>>>> limited just to the  changes that are really needed for the CS, and
>>>>> that will work with the  current CS model (minor maintenance releases
>>>>> support is a part of it)
>>>>> 
>>>>> 
>>>> 
>>>> Theoretically you don't really have to change anything other than
>>>> merging instead of cherry picking.
>>>> That is the main issue from a release perspective.
>>>> 
>>>> But I still think there are good reasons to do so;
>>>> 
>>>> 1) using a well known way of handling code/releases instantly tells new
>>>> contributors / committers how we work. add to the fact that there
>>>> exists tools to help doing this correctly is a bonus.
>>>> 2) having a known stable (atleast in theory) release as master is good
>>>> practice. although not many users will be running from git, i still
>>>> consider it to be good practice.
>>>> 3) there is a huge belief in this thread/discussion that as long as
>>>> something passes CI / BVT it is considered stable. The fact is that it
>>>> is not. Take the recent 4.4 release as a good example, where a new
>>>> install was not working at all at the point of release. Now, this is
>>>> more a CI / test coverage issue than git workflow issue, but i find it
>>>> weird to use as an argument for not improving the workflow.
>>>> 
>>>> --
>>>> Erik
>>> 
>>> I¹m not arguing against keeping master release stable; I advocate for
>>> it.
>> 
>> +1, we need to take action to make sure master is stable. Frankly
>> speaking, 
>> I don't want to fix the regression on the master, I assume nobody want to
>> do that.
>> Here is the list of regression issues(not introduced by myself) I fixed
>> on master after 4.4:
>> 
>> CLOUDSTACK-7123
>> CLOUDSTACK-7110
>> CLOUDSTACK-7166
>> CLOUDSTACK-7164
>> Most of this issues will be caught even by a simulator BVT. I want to
>> make it clear, that,
>> If we don't take action to reduce/eliminate the regression as much as
>> possible in the future, I will not fix any of this regression issues.
>> I remember there is discussion about setting up a staging branch, run BVT
>> against it for each commit, what's the conclusion if any? Why so
>> difficult to make it happen? Is there anything I can help to make it
>> happen?
>> 
>>> But we can¹t adopt git workflow way of keeping master branch to be a
>>> reflection of the latest release branch. It will not work with our way
>>> of
>>> handling maintenance releases for multiple versions of CS - see another
>>> thread.
>> 
>> 
>> +1, I'll -1 on any of proposal, if it doesn't solve problem most of us
>> are concerning about.
>> 
>>> 
>>> Instead, master branch should reflect the latest code that passed the
>>> CI test
>>> (the code merged from *develop after CI passes). The release branches
>>> should be cut from stable master branch - it will ensure that we won¹t
>>> face
>>> last minute blockers as for 4.4, because master IS a stable branch.
>>> And yes, we should do merges instead of cherry picking.
>>> 
>>> 
>>> 
>>>> 
>> 
> 

Re: [VOTE] git workflow

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

I am not advocating that we should follow git-flow.

If you see my original [proposal], it has no mention of git-flow. I just
felt that we are abusing git and put some points which could help us
improve.

Git-flow is something which I liked and felt that it would make us treat
git well.

I am okay with any proposal which addresses those.


I suggest not to discuss on this anymore. We had long discussions and still
failed to reach consensus.

lets put up a new one and I would be happy to vote.


David/Alena/anyone else,

Can you take this up and put a proposal for vote?



[proposal] http://markmail.org/message/dawo4oannrdgpfgs


On Thu, Aug 7, 2014 at 4:45 AM, David Nalley <da...@gnsa.us> wrote:

> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
> <Al...@citrix.com> wrote:
> > Edison, thank you for raising the concern about the BVT/CI. Somebody
> > mentioned earlier that we should separate git workflow implementation
> from
> > the CI effort, but I do think we have to do in in conjunction. Otherwise
> > what is the point in introducing staging/develop branch? If there is no
> > daily automation run verifying all the code merged from hotFixes/feature
> > branches (and possibly reverting wrong checkins), we can as well merge
> the
> > code directly to master.
> >
>
> Yes! - please.
> Doing this without CI as a gating factor buys us very little.
>
> --David
>



-- 
~Rajani

Re: [VOTE] git workflow

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

I see a lot of confusion around the fact that the name of gitflow is
being used. What was proposed was a model that could be supported by
the tool gitflow, not a workflow exactly as gitflow 'prescribes' it.
If we forget about gitflow for a moment and look at the branching
model that we want we all agree.

For instance the idea of a shift of our current master problems to
develop. it is there but half of the problems are shifted beyond
develop onto all those branches that we are going to create. develop
is going to suffer at times but it will keep the trouble away from
master, as it won't be merged when not passing bvt/ci.

In gitflow master is only for releases, in our model for all potential
major.minor releases, even if we don't release them. The only ones
that won't be on there are the conflicting bugfix releases.

As for the problem 'branch moving really fast', we can ask to only
merge to develop/master if the feature branch passes some test and
make it a committer responsibility to guard this. I think we have or
can make automatic records of passing or failing of feature branches.
this would be how we mitigate the second half of the problems, the
pre-merging regression ones. For now we would rely on each other but
that will alter.

On Thu, Aug 7, 2014 at 11:52 PM, Mike Tutkowski
<mi...@solidfire.com> wrote:
> This is what I was wondering about, as well. It seems all of our 'master'
> problems become 'develop' problems.
>
> I do like the idea of merging versus cherry picking (as a general rule),
> though.
>
>
> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
>> Sebastian, addressing the following comment of yours
>>
>>
>> "The main issue with master right now is that it moves really fast as a
>> shared branch, people merge features without warning, we see regressions
>> etc..
>> By the time we release a major version, master has moved so much that it
>> feels like starting over with the next release. It's almost as if we are
>> forking our own software. CI alone (even if it were really good) will not
>> fix this.”
>>
>>
>> You will still have this problem. You cut the next release branch from the
>> *develop branch, not from master. And the *develop branch will move with
>> the same pace as the old master, after the release branch is cut. So
>> “master moving really fast” problem would become “develop moving really
>> fast”.
>>
>> The problems you’ve mentioned - people merge features without warning, we
>> see regressions - can be fixed only with automation in place and the
>> requirement to run this automation (CI/BVT) before the merge is done.
>> Otherwise you are just shifting all existing problems from master to
>> develop.
>>
>>
>> -Alena.
>>
>>
>>
>> On 8/7/14, 2:15 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>
>> >
>> >On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>> ><Al...@citrix.com> wrote:
>> >
>> >>
>> >>
>> >> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>> >>
>> >>>
>> >>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:
>> >>>
>> >>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <ru...@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
>> >>>>>
>> >>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>> >>>>>> <Al...@citrix.com> wrote:
>> >>>>>>> Edison, thank you for raising the concern about the BVT/CI.
>> >>>>>>>Somebody
>> >>>>>>> mentioned earlier that we should separate git workflow
>> >>>>>>> implementation from
>> >>>>>>> the CI effort, but I do think we have to do in in conjunction.
>> >>>>>>> Otherwise
>> >>>>>>> what is the point in introducing staging/develop branch? If there
>> >>>>>>>is
>> >>>>>>> no
>> >>>>>>> daily automation run verifying all the code merged from
>> >>>>>>> hotFixes/feature
>> >>>>>>> branches (and possibly reverting wrong checkins), we can as well
>> >>>>>>> merge the
>> >>>>>>> code directly to master.
>> >>>>>>>
>> >>>>>>
>> >>>>>> Yes! - please.
>> >>>>>> Doing this without CI as a gating factor buys us very little.
>> >>>>>>
>> >>>>>> --David
>> >>>>>
>> >>>>> David, can you clarify. Are you going to be against any change of git
>> >>>>> workflow until we get CI/BVT in place ?
>> >>>>>
>> >>>>
>> >>>> No, please don't take it that way.
>> >>>> I understand Leo's point about Cherry-picking being for fruit, and not
>> >>>> code. But, I don't think that the workflow changes I've seen proposed
>> >>>> affect quality. So shifting for quality's sake doesn't make a lot of
>> >>>> sense in my mind. They could be a component of fixing the quality
>> >>>> problem.
>> >>>>
>> >>>> --David
>> >>>
>> >>> Agreed, the changes don't affect quality but should support a CI infra
>> >>> that helps improves quality.
>> >>>
>> >>> I do think the changes provide
>> >>>
>> >>> -a stable master that represent released software
>> >>
>> >>
>> >> You can always look at the latest release branch to get it,
>> >
>> >Yes I know how to get to the latest released software.
>> >
>> >I actually don't have good answers for your questions but I think Nate's
>> >email (couple emails back) answers a lot of them.
>> >
>> >> as we are
>> >> planning to keep them around to support maintenance. From the developer
>> >> stand point, I would be more interested in getting the latest stable
>> >>code,
>> >> not the latest stable release.
>> >
>> >I think that's fine from a developer standpoint. I tend to look at things
>> >from a user standpoint.
>> >I think a basic user who wants to check out source (because he builds his
>> >own packages), would like to checkout the latest master to get the latest
>> >released software (not everybody software projects works like this of
>> >course).
>> >
>> >The main issue with master right now is that it moves really fast as a
>> >shared branch, people merge features without warning, we see regressions
>> >etc..
>> >By the time we release a major version, master has moved so much that it
>> >feels like starting over with the next release. It's almost as if we are
>> >forking our own software. CI alone (even if it were really good) will not
>> >fix this.
>> >
>> >So assuming we have CI in place, we do need a better workflow (let's not
>> >call it gitflow anymore) to self-discipline ourselves.
>> >
>> >>
>> >> I don¹t see the use of stable master branch during the release either,
>> >>as
>> >> it reflects already released versions of the CS. And you never cut the
>> >> release from the stable master branch; you do cut it from *develop -
>> >> that¹s what the git workflow suggests.
>> >
>> >That's where our use case differs from gitflow. Several folks have
>> >already mentioned that we are going to deviate from pure gitflow, it is
>> >just a nice framework to start creating our own workflow.
>> >
>> >Personally, I would love to cut the release branches from master (instead
>> >of develop). that way you always start from a clean slate, instead of the
>> >mess with start with right now.
>> >
>> >Say develop is more of a staging branch, as you have advocated. We can
>> >run CI/BVT on that branch (we should run it everywhere…but anyway) and
>> >make sure features merged in work as advertized.
>> >
>> >When time comes to release, we cut from master and merge the features
>> >that have been merged in develop already, then go into QA, merge the
>> >fixes back to develop etc….when released, we merge back to master.
>> >
>> >If/since we don't do rolling releases, we branch out from the main
>> >version tag and do a maintenance release that leaves on, assuming it
>> >can't get merged back into master.
>> >
>> >>
>> >>> -a clean way to merge features and bug fixes
>> >>
>> >> +1
>> >>
>> >>> -a clean way to create a release that should reduce our time to release
>> >>
>> >> +1 Although I still think that slowness for our release was mostly
>> >>caused
>> >> by the last minute regression bugs caused by missing quality control +
>> >> lack of CI.
>> >
>> >True, but it is also due to the fact that we start a release branch from
>> >a messy master where regressions happen.
>> >
>> >> This new way would just take off the load from RM by
>> >> eliminating endless cherry-picking.
>> >>
>> >
>> >I would love to have a workflow where the RM has a very clean job (pick
>> >the features that should be in the release, pick the hot fixes release).
>> >It should just be a series of git merge and that's it.
>> >
>> >master branch is only released software, only touched by RMs
>> >
>> >released branches only touched by RMs
>> >
>> >develop shared but merges happen only after successful CI and guarantee
>> >of no regressions.
>> >
>> >>
>> >>>
>> >>
>> >
>>
>>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*



-- 
Daan

Re: [VOTE] git workflow

[Sheng Yang <sh...@yasker.org>]

Rohit,

Thank you to bring this to a end.

Finally handling multiple maintenance release is recognized as an issue in
this model.

--Sheng

On Fri, Aug 8, 2014 at 4:28 AM, Rohit Yadav <ro...@shapeblue.com>
wrote:

> Hi,
>
> Vincent (nvie) has allowed me to share his email publicly, here you go:
>
> "
> Hi Rohit,
>
> Thanks for reaching out. I don't think git-flow suits your use case very
> well. Git flow was mainly optimized as a set of rules to help bring forth
> "forward-only" releases, and does not support multiple concurrent and
> non-chronological releases very well. The main reason is that getting all
> the details down leads to much complexity. Back when the git-flow model was
> devised it was meant to be a rule set that could be automated, and aimed at
> a single release stream. Adding multiple concurrent releases would
> significantly complicate the model.
>
> I have no advice on what model would work better for you. Of course you
> could make a variant of git-flow that works with multiple "master"
> branches, one for each release, but the exact semantics of which of those
> to merge hot fixes in, for example, are not documented somewhere formally.
>
> Cheers,
> Vincent
> “
>
> On 08-Aug-2014, at 9:23 am, Daan Hoogland <da...@gmail.com> wrote:
>
> > Rohit, this is not a git-flow or gitflow discussion. It seems to be at
> > times but it is not. It is a discussion about how to branch in our
> > repository. That discussion should not end, but maybe so in this
> > thread.
> >
> > On Fri, Aug 8, 2014 at 9:19 AM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
> >> Hi all,
> >>
> >> Let’s end this discussion thread.
> >>
> >> I asked Vincent (nvie) and some friends from google and facebook on
> this and all of them recommended that this is not for us; then I read the
> whole thread again without prejudice or ego and I think it’s not for us
> though we should pick up couple of good ideas from it:
> >>
> >> - git-flow was designed for only “forward” releases
> >> - git-flow does not support multiple concurrent and non-chronological
> releases/support very well (no nvie documentation on how to do that)
> >>
> >> Instead, if you’re interested on such topic I started a proposal
> (inspired by couple of workflows) on solving cherry-picking issue by
> adapting our release/master workflow please have a look on that. Some good
> reads on other git workflows we can get ideas from;
> >>
> >>
> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows
> (my new proposal uses this idea)
> >> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
> (read this at least once)
> >>
> >> PS. Let me know privately if you want me to forward you Vincent’s email
> >>
> >> On 07-Aug-2014, at 11:52 pm, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
> >>
> >>> This is what I was wondering about, as well. It seems all of our
> 'master'
> >>> problems become 'develop' problems.
> >>>
> >>> I do like the idea of merging versus cherry picking (as a general
> rule),
> >>> though.
> >>>
> >>>
> >>> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
> >>> Alena.Prokharchyk@citrix.com> wrote:
> >>>
> >>>> Sebastian, addressing the following comment of yours
> >>>>
> >>>>
> >>>> "The main issue with master right now is that it moves really fast as
> a
> >>>> shared branch, people merge features without warning, we see
> regressions
> >>>> etc..
> >>>> By the time we release a major version, master has moved so much that
> it
> >>>> feels like starting over with the next release. It's almost as if we
> are
> >>>> forking our own software. CI alone (even if it were really good) will
> not
> >>>> fix this.”
> >>>>
> >>>>
> >>>> You will still have this problem. You cut the next release branch
> from the
> >>>> *develop branch, not from master. And the *develop branch will move
> with
> >>>> the same pace as the old master, after the release branch is cut. So
> >>>> “master moving really fast” problem would become “develop moving
> really
> >>>> fast”.
> >>>>
> >>>> The problems you’ve mentioned - people merge features without
> warning, we
> >>>> see regressions - can be fixed only with automation in place and the
> >>>> requirement to run this automation (CI/BVT) before the merge is done.
> >>>> Otherwise you are just shifting all existing problems from master to
> >>>> develop.
> >>>>
> >>>>
> >>>> -Alena.
> >>>>
> >>>>
> >>>>
> >>>> On 8/7/14, 2:15 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
> >>>>
> >>>>>
> >>>>> On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
> >>>>> <Al...@citrix.com> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:
> >>>>>>>
> >>>>>>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <
> runseb@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
> >>>>>>>>>> <Al...@citrix.com> wrote:
> >>>>>>>>>>> Edison, thank you for raising the concern about the BVT/CI.
> >>>>>>>>>>> Somebody
> >>>>>>>>>>> mentioned earlier that we should separate git workflow
> >>>>>>>>>>> implementation from
> >>>>>>>>>>> the CI effort, but I do think we have to do in in conjunction.
> >>>>>>>>>>> Otherwise
> >>>>>>>>>>> what is the point in introducing staging/develop branch? If
> there
> >>>>>>>>>>> is
> >>>>>>>>>>> no
> >>>>>>>>>>> daily automation run verifying all the code merged from
> >>>>>>>>>>> hotFixes/feature
> >>>>>>>>>>> branches (and possibly reverting wrong checkins), we can as
> well
> >>>>>>>>>>> merge the
> >>>>>>>>>>> code directly to master.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Yes! - please.
> >>>>>>>>>> Doing this without CI as a gating factor buys us very little.
> >>>>>>>>>>
> >>>>>>>>>> --David
> >>>>>>>>>
> >>>>>>>>> David, can you clarify. Are you going to be against any change
> of git
> >>>>>>>>> workflow until we get CI/BVT in place ?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> No, please don't take it that way.
> >>>>>>>> I understand Leo's point about Cherry-picking being for fruit,
> and not
> >>>>>>>> code. But, I don't think that the workflow changes I've seen
> proposed
> >>>>>>>> affect quality. So shifting for quality's sake doesn't make a lot
> of
> >>>>>>>> sense in my mind. They could be a component of fixing the quality
> >>>>>>>> problem.
> >>>>>>>>
> >>>>>>>> --David
> >>>>>>>
> >>>>>>> Agreed, the changes don't affect quality but should support a CI
> infra
> >>>>>>> that helps improves quality.
> >>>>>>>
> >>>>>>> I do think the changes provide
> >>>>>>>
> >>>>>>> -a stable master that represent released software
> >>>>>>
> >>>>>>
> >>>>>> You can always look at the latest release branch to get it,
> >>>>>
> >>>>> Yes I know how to get to the latest released software.
> >>>>>
> >>>>> I actually don't have good answers for your questions but I think
> Nate's
> >>>>> email (couple emails back) answers a lot of them.
> >>>>>
> >>>>>> as we are
> >>>>>> planning to keep them around to support maintenance. From the
> developer
> >>>>>> stand point, I would be more interested in getting the latest stable
> >>>>>> code,
> >>>>>> not the latest stable release.
> >>>>>
> >>>>> I think that's fine from a developer standpoint. I tend to look at
> things
> >>>>> from a user standpoint.
> >>>>> I think a basic user who wants to check out source (because he
> builds his
> >>>>> own packages), would like to checkout the latest master to get the
> latest
> >>>>> released software (not everybody software projects works like this of
> >>>>> course).
> >>>>>
> >>>>> The main issue with master right now is that it moves really fast as
> a
> >>>>> shared branch, people merge features without warning, we see
> regressions
> >>>>> etc..
> >>>>> By the time we release a major version, master has moved so much
> that it
> >>>>> feels like starting over with the next release. It's almost as if we
> are
> >>>>> forking our own software. CI alone (even if it were really good)
> will not
> >>>>> fix this.
> >>>>>
> >>>>> So assuming we have CI in place, we do need a better workflow (let's
> not
> >>>>> call it gitflow anymore) to self-discipline ourselves.
> >>>>>
> >>>>>>
> >>>>>> I don¹t see the use of stable master branch during the release
> either,
> >>>>>> as
> >>>>>> it reflects already released versions of the CS. And you never cut
> the
> >>>>>> release from the stable master branch; you do cut it from *develop -
> >>>>>> that¹s what the git workflow suggests.
> >>>>>
> >>>>> That's where our use case differs from gitflow. Several folks have
> >>>>> already mentioned that we are going to deviate from pure gitflow, it
> is
> >>>>> just a nice framework to start creating our own workflow.
> >>>>>
> >>>>> Personally, I would love to cut the release branches from master
> (instead
> >>>>> of develop). that way you always start from a clean slate, instead
> of the
> >>>>> mess with start with right now.
> >>>>>
> >>>>> Say develop is more of a staging branch, as you have advocated. We
> can
> >>>>> run CI/BVT on that branch (we should run it everywhere…but anyway)
> and
> >>>>> make sure features merged in work as advertized.
> >>>>>
> >>>>> When time comes to release, we cut from master and merge the features
> >>>>> that have been merged in develop already, then go into QA, merge the
> >>>>> fixes back to develop etc….when released, we merge back to master.
> >>>>>
> >>>>> If/since we don't do rolling releases, we branch out from the main
> >>>>> version tag and do a maintenance release that leaves on, assuming it
> >>>>> can't get merged back into master.
> >>>>>
> >>>>>>
> >>>>>>> -a clean way to merge features and bug fixes
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>>> -a clean way to create a release that should reduce our time to
> release
> >>>>>>
> >>>>>> +1 Although I still think that slowness for our release was mostly
> >>>>>> caused
> >>>>>> by the last minute regression bugs caused by missing quality
> control +
> >>>>>> lack of CI.
> >>>>>
> >>>>> True, but it is also due to the fact that we start a release branch
> from
> >>>>> a messy master where regressions happen.
> >>>>>
> >>>>>> This new way would just take off the load from RM by
> >>>>>> eliminating endless cherry-picking.
> >>>>>>
> >>>>>
> >>>>> I would love to have a workflow where the RM has a very clean job
> (pick
> >>>>> the features that should be in the release, pick the hot fixes
> release).
> >>>>> It should just be a series of git merge and that's it.
> >>>>>
> >>>>> master branch is only released software, only touched by RMs
> >>>>>
> >>>>> released branches only touched by RMs
> >>>>>
> >>>>> develop shared but merges happen only after successful CI and
> guarantee
> >>>>> of no regressions.
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> *Mike Tutkowski*
> >>> *Senior CloudStack Developer, SolidFire Inc.*
> >>> e: mike.tutkowski@solidfire.com
> >>> o: 303.746.7302
> >>> Advancing the way the world uses the cloud
> >>> <http://solidfire.com/solution/overview/?video=play>*™*
> >>
> >> 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] git workflow

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

This sounds like an end goal that we shouldn't try to reach in one go.
Let's take baby steps.

On Fri, Aug 8, 2014 at 1:28 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hi,
>
> Vincent (nvie) has allowed me to share his email publicly, here you go:
>
> "
> Hi Rohit,
>
> Thanks for reaching out. I don't think git-flow suits your use case very well. Git flow was mainly optimized as a set of rules to help bring forth "forward-only" releases, and does not support multiple concurrent and non-chronological releases very well. The main reason is that getting all the details down leads to much complexity. Back when the git-flow model was devised it was meant to be a rule set that could be automated, and aimed at a single release stream. Adding multiple concurrent releases would significantly complicate the model.
>
> I have no advice on what model would work better for you. Of course you could make a variant of git-flow that works with multiple "master" branches, one for each release, but the exact semantics of which of those to merge hot fixes in, for example, are not documented somewhere formally.
>
> Cheers,
> Vincent
> “
>
> On 08-Aug-2014, at 9:23 am, Daan Hoogland <da...@gmail.com> wrote:
>
>> Rohit, this is not a git-flow or gitflow discussion. It seems to be at
>> times but it is not. It is a discussion about how to branch in our
>> repository. That discussion should not end, but maybe so in this
>> thread.
>>
>> On Fri, Aug 8, 2014 at 9:19 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>> Hi all,
>>>
>>> Let’s end this discussion thread.
>>>
>>> I asked Vincent (nvie) and some friends from google and facebook on this and all of them recommended that this is not for us; then I read the whole thread again without prejudice or ego and I think it’s not for us though we should pick up couple of good ideas from it:
>>>
>>> - git-flow was designed for only “forward” releases
>>> - git-flow does not support multiple concurrent and non-chronological releases/support very well (no nvie documentation on how to do that)
>>>
>>> Instead, if you’re interested on such topic I started a proposal (inspired by couple of workflows) on solving cherry-picking issue by adapting our release/master workflow please have a look on that. Some good reads on other git workflows we can get ideas from;
>>>
>>> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows (my new proposal uses this idea)
>>> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html (read this at least once)
>>>
>>> PS. Let me know privately if you want me to forward you Vincent’s email
>>>
>>> On 07-Aug-2014, at 11:52 pm, Mike Tutkowski <mi...@solidfire.com> wrote:
>>>
>>>> This is what I was wondering about, as well. It seems all of our 'master'
>>>> problems become 'develop' problems.
>>>>
>>>> I do like the idea of merging versus cherry picking (as a general rule),
>>>> though.
>>>>
>>>>
>>>> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>>
>>>>> Sebastian, addressing the following comment of yours
>>>>>
>>>>>
>>>>> "The main issue with master right now is that it moves really fast as a
>>>>> shared branch, people merge features without warning, we see regressions
>>>>> etc..
>>>>> By the time we release a major version, master has moved so much that it
>>>>> feels like starting over with the next release. It's almost as if we are
>>>>> forking our own software. CI alone (even if it were really good) will not
>>>>> fix this.”
>>>>>
>>>>>
>>>>> You will still have this problem. You cut the next release branch from the
>>>>> *develop branch, not from master. And the *develop branch will move with
>>>>> the same pace as the old master, after the release branch is cut. So
>>>>> “master moving really fast” problem would become “develop moving really
>>>>> fast”.
>>>>>
>>>>> The problems you’ve mentioned - people merge features without warning, we
>>>>> see regressions - can be fixed only with automation in place and the
>>>>> requirement to run this automation (CI/BVT) before the merge is done.
>>>>> Otherwise you are just shifting all existing problems from master to
>>>>> develop.
>>>>>
>>>>>
>>>>> -Alena.
>>>>>
>>>>>
>>>>>
>>>>> On 8/7/14, 2:15 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>>>>>> <Al...@citrix.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>>
>>>>>>>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <ru...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>>>>>>>>>> <Al...@citrix.com> wrote:
>>>>>>>>>>>> Edison, thank you for raising the concern about the BVT/CI.
>>>>>>>>>>>> Somebody
>>>>>>>>>>>> mentioned earlier that we should separate git workflow
>>>>>>>>>>>> implementation from
>>>>>>>>>>>> the CI effort, but I do think we have to do in in conjunction.
>>>>>>>>>>>> Otherwise
>>>>>>>>>>>> what is the point in introducing staging/develop branch? If there
>>>>>>>>>>>> is
>>>>>>>>>>>> no
>>>>>>>>>>>> daily automation run verifying all the code merged from
>>>>>>>>>>>> hotFixes/feature
>>>>>>>>>>>> branches (and possibly reverting wrong checkins), we can as well
>>>>>>>>>>>> merge the
>>>>>>>>>>>> code directly to master.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes! - please.
>>>>>>>>>>> Doing this without CI as a gating factor buys us very little.
>>>>>>>>>>>
>>>>>>>>>>> --David
>>>>>>>>>>
>>>>>>>>>> David, can you clarify. Are you going to be against any change of git
>>>>>>>>>> workflow until we get CI/BVT in place ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, please don't take it that way.
>>>>>>>>> I understand Leo's point about Cherry-picking being for fruit, and not
>>>>>>>>> code. But, I don't think that the workflow changes I've seen proposed
>>>>>>>>> affect quality. So shifting for quality's sake doesn't make a lot of
>>>>>>>>> sense in my mind. They could be a component of fixing the quality
>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>> --David
>>>>>>>>
>>>>>>>> Agreed, the changes don't affect quality but should support a CI infra
>>>>>>>> that helps improves quality.
>>>>>>>>
>>>>>>>> I do think the changes provide
>>>>>>>>
>>>>>>>> -a stable master that represent released software
>>>>>>>
>>>>>>>
>>>>>>> You can always look at the latest release branch to get it,
>>>>>>
>>>>>> Yes I know how to get to the latest released software.
>>>>>>
>>>>>> I actually don't have good answers for your questions but I think Nate's
>>>>>> email (couple emails back) answers a lot of them.
>>>>>>
>>>>>>> as we are
>>>>>>> planning to keep them around to support maintenance. From the developer
>>>>>>> stand point, I would be more interested in getting the latest stable
>>>>>>> code,
>>>>>>> not the latest stable release.
>>>>>>
>>>>>> I think that's fine from a developer standpoint. I tend to look at things
>>>>>> from a user standpoint.
>>>>>> I think a basic user who wants to check out source (because he builds his
>>>>>> own packages), would like to checkout the latest master to get the latest
>>>>>> released software (not everybody software projects works like this of
>>>>>> course).
>>>>>>
>>>>>> The main issue with master right now is that it moves really fast as a
>>>>>> shared branch, people merge features without warning, we see regressions
>>>>>> etc..
>>>>>> By the time we release a major version, master has moved so much that it
>>>>>> feels like starting over with the next release. It's almost as if we are
>>>>>> forking our own software. CI alone (even if it were really good) will not
>>>>>> fix this.
>>>>>>
>>>>>> So assuming we have CI in place, we do need a better workflow (let's not
>>>>>> call it gitflow anymore) to self-discipline ourselves.
>>>>>>
>>>>>>>
>>>>>>> I don¹t see the use of stable master branch during the release either,
>>>>>>> as
>>>>>>> it reflects already released versions of the CS. And you never cut the
>>>>>>> release from the stable master branch; you do cut it from *develop -
>>>>>>> that¹s what the git workflow suggests.
>>>>>>
>>>>>> That's where our use case differs from gitflow. Several folks have
>>>>>> already mentioned that we are going to deviate from pure gitflow, it is
>>>>>> just a nice framework to start creating our own workflow.
>>>>>>
>>>>>> Personally, I would love to cut the release branches from master (instead
>>>>>> of develop). that way you always start from a clean slate, instead of the
>>>>>> mess with start with right now.
>>>>>>
>>>>>> Say develop is more of a staging branch, as you have advocated. We can
>>>>>> run CI/BVT on that branch (we should run it everywhere…but anyway) and
>>>>>> make sure features merged in work as advertized.
>>>>>>
>>>>>> When time comes to release, we cut from master and merge the features
>>>>>> that have been merged in develop already, then go into QA, merge the
>>>>>> fixes back to develop etc….when released, we merge back to master.
>>>>>>
>>>>>> If/since we don't do rolling releases, we branch out from the main
>>>>>> version tag and do a maintenance release that leaves on, assuming it
>>>>>> can't get merged back into master.
>>>>>>
>>>>>>>
>>>>>>>> -a clean way to merge features and bug fixes
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>> -a clean way to create a release that should reduce our time to release
>>>>>>>
>>>>>>> +1 Although I still think that slowness for our release was mostly
>>>>>>> caused
>>>>>>> by the last minute regression bugs caused by missing quality control +
>>>>>>> lack of CI.
>>>>>>
>>>>>> True, but it is also due to the fact that we start a release branch from
>>>>>> a messy master where regressions happen.
>>>>>>
>>>>>>> This new way would just take off the load from RM by
>>>>>>> eliminating endless cherry-picking.
>>>>>>>
>>>>>>
>>>>>> I would love to have a workflow where the RM has a very clean job (pick
>>>>>> the features that should be in the release, pick the hot fixes release).
>>>>>> It should just be a series of git merge and that's it.
>>>>>>
>>>>>> master branch is only released software, only touched by RMs
>>>>>>
>>>>>> released branches only touched by RMs
>>>>>>
>>>>>> develop shared but merges happen only after successful CI and guarantee
>>>>>> of no regressions.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Mike Tutkowski*
>>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>> e: mike.tutkowski@solidfire.com
>>>> o: 303.746.7302
>>>> Advancing the way the world uses the cloud
>>>> <http://solidfire.com/solution/overview/?video=play>*™*
>>>
>>> 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.



-- 
Daan

Re: [VOTE] git workflow

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

Hi,

Vincent (nvie) has allowed me to share his email publicly, here you go:

"
Hi Rohit,

Thanks for reaching out. I don't think git-flow suits your use case very well. Git flow was mainly optimized as a set of rules to help bring forth "forward-only" releases, and does not support multiple concurrent and non-chronological releases very well. The main reason is that getting all the details down leads to much complexity. Back when the git-flow model was devised it was meant to be a rule set that could be automated, and aimed at a single release stream. Adding multiple concurrent releases would significantly complicate the model.

I have no advice on what model would work better for you. Of course you could make a variant of git-flow that works with multiple "master" branches, one for each release, but the exact semantics of which of those to merge hot fixes in, for example, are not documented somewhere formally.

Cheers,
Vincent
“

On 08-Aug-2014, at 9:23 am, Daan Hoogland <da...@gmail.com> wrote:

> Rohit, this is not a git-flow or gitflow discussion. It seems to be at
> times but it is not. It is a discussion about how to branch in our
> repository. That discussion should not end, but maybe so in this
> thread.
>
> On Fri, Aug 8, 2014 at 9:19 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
>> Hi all,
>>
>> Let’s end this discussion thread.
>>
>> I asked Vincent (nvie) and some friends from google and facebook on this and all of them recommended that this is not for us; then I read the whole thread again without prejudice or ego and I think it’s not for us though we should pick up couple of good ideas from it:
>>
>> - git-flow was designed for only “forward” releases
>> - git-flow does not support multiple concurrent and non-chronological releases/support very well (no nvie documentation on how to do that)
>>
>> Instead, if you’re interested on such topic I started a proposal (inspired by couple of workflows) on solving cherry-picking issue by adapting our release/master workflow please have a look on that. Some good reads on other git workflows we can get ideas from;
>>
>> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows (my new proposal uses this idea)
>> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html (read this at least once)
>>
>> PS. Let me know privately if you want me to forward you Vincent’s email
>>
>> On 07-Aug-2014, at 11:52 pm, Mike Tutkowski <mi...@solidfire.com> wrote:
>>
>>> This is what I was wondering about, as well. It seems all of our 'master'
>>> problems become 'develop' problems.
>>>
>>> I do like the idea of merging versus cherry picking (as a general rule),
>>> though.
>>>
>>>
>>> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
>>> Alena.Prokharchyk@citrix.com> wrote:
>>>
>>>> Sebastian, addressing the following comment of yours
>>>>
>>>>
>>>> "The main issue with master right now is that it moves really fast as a
>>>> shared branch, people merge features without warning, we see regressions
>>>> etc..
>>>> By the time we release a major version, master has moved so much that it
>>>> feels like starting over with the next release. It's almost as if we are
>>>> forking our own software. CI alone (even if it were really good) will not
>>>> fix this.”
>>>>
>>>>
>>>> You will still have this problem. You cut the next release branch from the
>>>> *develop branch, not from master. And the *develop branch will move with
>>>> the same pace as the old master, after the release branch is cut. So
>>>> “master moving really fast” problem would become “develop moving really
>>>> fast”.
>>>>
>>>> The problems you’ve mentioned - people merge features without warning, we
>>>> see regressions - can be fixed only with automation in place and the
>>>> requirement to run this automation (CI/BVT) before the merge is done.
>>>> Otherwise you are just shifting all existing problems from master to
>>>> develop.
>>>>
>>>>
>>>> -Alena.
>>>>
>>>>
>>>>
>>>> On 8/7/14, 2:15 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>>>
>>>>>
>>>>> On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>>>>> <Al...@citrix.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>
>>>>>>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <ru...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>>>>>>>>> <Al...@citrix.com> wrote:
>>>>>>>>>>> Edison, thank you for raising the concern about the BVT/CI.
>>>>>>>>>>> Somebody
>>>>>>>>>>> mentioned earlier that we should separate git workflow
>>>>>>>>>>> implementation from
>>>>>>>>>>> the CI effort, but I do think we have to do in in conjunction.
>>>>>>>>>>> Otherwise
>>>>>>>>>>> what is the point in introducing staging/develop branch? If there
>>>>>>>>>>> is
>>>>>>>>>>> no
>>>>>>>>>>> daily automation run verifying all the code merged from
>>>>>>>>>>> hotFixes/feature
>>>>>>>>>>> branches (and possibly reverting wrong checkins), we can as well
>>>>>>>>>>> merge the
>>>>>>>>>>> code directly to master.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes! - please.
>>>>>>>>>> Doing this without CI as a gating factor buys us very little.
>>>>>>>>>>
>>>>>>>>>> --David
>>>>>>>>>
>>>>>>>>> David, can you clarify. Are you going to be against any change of git
>>>>>>>>> workflow until we get CI/BVT in place ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, please don't take it that way.
>>>>>>>> I understand Leo's point about Cherry-picking being for fruit, and not
>>>>>>>> code. But, I don't think that the workflow changes I've seen proposed
>>>>>>>> affect quality. So shifting for quality's sake doesn't make a lot of
>>>>>>>> sense in my mind. They could be a component of fixing the quality
>>>>>>>> problem.
>>>>>>>>
>>>>>>>> --David
>>>>>>>
>>>>>>> Agreed, the changes don't affect quality but should support a CI infra
>>>>>>> that helps improves quality.
>>>>>>>
>>>>>>> I do think the changes provide
>>>>>>>
>>>>>>> -a stable master that represent released software
>>>>>>
>>>>>>
>>>>>> You can always look at the latest release branch to get it,
>>>>>
>>>>> Yes I know how to get to the latest released software.
>>>>>
>>>>> I actually don't have good answers for your questions but I think Nate's
>>>>> email (couple emails back) answers a lot of them.
>>>>>
>>>>>> as we are
>>>>>> planning to keep them around to support maintenance. From the developer
>>>>>> stand point, I would be more interested in getting the latest stable
>>>>>> code,
>>>>>> not the latest stable release.
>>>>>
>>>>> I think that's fine from a developer standpoint. I tend to look at things
>>>>> from a user standpoint.
>>>>> I think a basic user who wants to check out source (because he builds his
>>>>> own packages), would like to checkout the latest master to get the latest
>>>>> released software (not everybody software projects works like this of
>>>>> course).
>>>>>
>>>>> The main issue with master right now is that it moves really fast as a
>>>>> shared branch, people merge features without warning, we see regressions
>>>>> etc..
>>>>> By the time we release a major version, master has moved so much that it
>>>>> feels like starting over with the next release. It's almost as if we are
>>>>> forking our own software. CI alone (even if it were really good) will not
>>>>> fix this.
>>>>>
>>>>> So assuming we have CI in place, we do need a better workflow (let's not
>>>>> call it gitflow anymore) to self-discipline ourselves.
>>>>>
>>>>>>
>>>>>> I don¹t see the use of stable master branch during the release either,
>>>>>> as
>>>>>> it reflects already released versions of the CS. And you never cut the
>>>>>> release from the stable master branch; you do cut it from *develop -
>>>>>> that¹s what the git workflow suggests.
>>>>>
>>>>> That's where our use case differs from gitflow. Several folks have
>>>>> already mentioned that we are going to deviate from pure gitflow, it is
>>>>> just a nice framework to start creating our own workflow.
>>>>>
>>>>> Personally, I would love to cut the release branches from master (instead
>>>>> of develop). that way you always start from a clean slate, instead of the
>>>>> mess with start with right now.
>>>>>
>>>>> Say develop is more of a staging branch, as you have advocated. We can
>>>>> run CI/BVT on that branch (we should run it everywhere…but anyway) and
>>>>> make sure features merged in work as advertized.
>>>>>
>>>>> When time comes to release, we cut from master and merge the features
>>>>> that have been merged in develop already, then go into QA, merge the
>>>>> fixes back to develop etc….when released, we merge back to master.
>>>>>
>>>>> If/since we don't do rolling releases, we branch out from the main
>>>>> version tag and do a maintenance release that leaves on, assuming it
>>>>> can't get merged back into master.
>>>>>
>>>>>>
>>>>>>> -a clean way to merge features and bug fixes
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>> -a clean way to create a release that should reduce our time to release
>>>>>>
>>>>>> +1 Although I still think that slowness for our release was mostly
>>>>>> caused
>>>>>> by the last minute regression bugs caused by missing quality control +
>>>>>> lack of CI.
>>>>>
>>>>> True, but it is also due to the fact that we start a release branch from
>>>>> a messy master where regressions happen.
>>>>>
>>>>>> This new way would just take off the load from RM by
>>>>>> eliminating endless cherry-picking.
>>>>>>
>>>>>
>>>>> I would love to have a workflow where the RM has a very clean job (pick
>>>>> the features that should be in the release, pick the hot fixes release).
>>>>> It should just be a series of git merge and that's it.
>>>>>
>>>>> master branch is only released software, only touched by RMs
>>>>>
>>>>> released branches only touched by RMs
>>>>>
>>>>> develop shared but merges happen only after successful CI and guarantee
>>>>> of no regressions.
>>>>>
>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkowski@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the cloud
>>> <http://solidfire.com/solution/overview/?video=play>*™*
>>
>> 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] git workflow

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

Rohit, this is not a git-flow or gitflow discussion. It seems to be at
times but it is not. It is a discussion about how to branch in our
repository. That discussion should not end, but maybe so in this
thread.

On Fri, Aug 8, 2014 at 9:19 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hi all,
>
> Let’s end this discussion thread.
>
> I asked Vincent (nvie) and some friends from google and facebook on this and all of them recommended that this is not for us; then I read the whole thread again without prejudice or ego and I think it’s not for us though we should pick up couple of good ideas from it:
>
> - git-flow was designed for only “forward” releases
> - git-flow does not support multiple concurrent and non-chronological releases/support very well (no nvie documentation on how to do that)
>
> Instead, if you’re interested on such topic I started a proposal (inspired by couple of workflows) on solving cherry-picking issue by adapting our release/master workflow please have a look on that. Some good reads on other git workflows we can get ideas from;
>
> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows (my new proposal uses this idea)
> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html (read this at least once)
>
> PS. Let me know privately if you want me to forward you Vincent’s email
>
> On 07-Aug-2014, at 11:52 pm, Mike Tutkowski <mi...@solidfire.com> wrote:
>
>> This is what I was wondering about, as well. It seems all of our 'master'
>> problems become 'develop' problems.
>>
>> I do like the idea of merging versus cherry picking (as a general rule),
>> though.
>>
>>
>> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
>> Alena.Prokharchyk@citrix.com> wrote:
>>
>>> Sebastian, addressing the following comment of yours
>>>
>>>
>>> "The main issue with master right now is that it moves really fast as a
>>> shared branch, people merge features without warning, we see regressions
>>> etc..
>>> By the time we release a major version, master has moved so much that it
>>> feels like starting over with the next release. It's almost as if we are
>>> forking our own software. CI alone (even if it were really good) will not
>>> fix this.”
>>>
>>>
>>> You will still have this problem. You cut the next release branch from the
>>> *develop branch, not from master. And the *develop branch will move with
>>> the same pace as the old master, after the release branch is cut. So
>>> “master moving really fast” problem would become “develop moving really
>>> fast”.
>>>
>>> The problems you’ve mentioned - people merge features without warning, we
>>> see regressions - can be fixed only with automation in place and the
>>> requirement to run this automation (CI/BVT) before the merge is done.
>>> Otherwise you are just shifting all existing problems from master to
>>> develop.
>>>
>>>
>>> -Alena.
>>>
>>>
>>>
>>> On 8/7/14, 2:15 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>>
>>>>
>>>> On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>>>> <Al...@citrix.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>
>>>>>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <ru...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>>>>>>>> <Al...@citrix.com> wrote:
>>>>>>>>>> Edison, thank you for raising the concern about the BVT/CI.
>>>>>>>>>> Somebody
>>>>>>>>>> mentioned earlier that we should separate git workflow
>>>>>>>>>> implementation from
>>>>>>>>>> the CI effort, but I do think we have to do in in conjunction.
>>>>>>>>>> Otherwise
>>>>>>>>>> what is the point in introducing staging/develop branch? If there
>>>>>>>>>> is
>>>>>>>>>> no
>>>>>>>>>> daily automation run verifying all the code merged from
>>>>>>>>>> hotFixes/feature
>>>>>>>>>> branches (and possibly reverting wrong checkins), we can as well
>>>>>>>>>> merge the
>>>>>>>>>> code directly to master.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes! - please.
>>>>>>>>> Doing this without CI as a gating factor buys us very little.
>>>>>>>>>
>>>>>>>>> --David
>>>>>>>>
>>>>>>>> David, can you clarify. Are you going to be against any change of git
>>>>>>>> workflow until we get CI/BVT in place ?
>>>>>>>>
>>>>>>>
>>>>>>> No, please don't take it that way.
>>>>>>> I understand Leo's point about Cherry-picking being for fruit, and not
>>>>>>> code. But, I don't think that the workflow changes I've seen proposed
>>>>>>> affect quality. So shifting for quality's sake doesn't make a lot of
>>>>>>> sense in my mind. They could be a component of fixing the quality
>>>>>>> problem.
>>>>>>>
>>>>>>> --David
>>>>>>
>>>>>> Agreed, the changes don't affect quality but should support a CI infra
>>>>>> that helps improves quality.
>>>>>>
>>>>>> I do think the changes provide
>>>>>>
>>>>>> -a stable master that represent released software
>>>>>
>>>>>
>>>>> You can always look at the latest release branch to get it,
>>>>
>>>> Yes I know how to get to the latest released software.
>>>>
>>>> I actually don't have good answers for your questions but I think Nate's
>>>> email (couple emails back) answers a lot of them.
>>>>
>>>>> as we are
>>>>> planning to keep them around to support maintenance. From the developer
>>>>> stand point, I would be more interested in getting the latest stable
>>>>> code,
>>>>> not the latest stable release.
>>>>
>>>> I think that's fine from a developer standpoint. I tend to look at things
>>>> from a user standpoint.
>>>> I think a basic user who wants to check out source (because he builds his
>>>> own packages), would like to checkout the latest master to get the latest
>>>> released software (not everybody software projects works like this of
>>>> course).
>>>>
>>>> The main issue with master right now is that it moves really fast as a
>>>> shared branch, people merge features without warning, we see regressions
>>>> etc..
>>>> By the time we release a major version, master has moved so much that it
>>>> feels like starting over with the next release. It's almost as if we are
>>>> forking our own software. CI alone (even if it were really good) will not
>>>> fix this.
>>>>
>>>> So assuming we have CI in place, we do need a better workflow (let's not
>>>> call it gitflow anymore) to self-discipline ourselves.
>>>>
>>>>>
>>>>> I don¹t see the use of stable master branch during the release either,
>>>>> as
>>>>> it reflects already released versions of the CS. And you never cut the
>>>>> release from the stable master branch; you do cut it from *develop -
>>>>> that¹s what the git workflow suggests.
>>>>
>>>> That's where our use case differs from gitflow. Several folks have
>>>> already mentioned that we are going to deviate from pure gitflow, it is
>>>> just a nice framework to start creating our own workflow.
>>>>
>>>> Personally, I would love to cut the release branches from master (instead
>>>> of develop). that way you always start from a clean slate, instead of the
>>>> mess with start with right now.
>>>>
>>>> Say develop is more of a staging branch, as you have advocated. We can
>>>> run CI/BVT on that branch (we should run it everywhere…but anyway) and
>>>> make sure features merged in work as advertized.
>>>>
>>>> When time comes to release, we cut from master and merge the features
>>>> that have been merged in develop already, then go into QA, merge the
>>>> fixes back to develop etc….when released, we merge back to master.
>>>>
>>>> If/since we don't do rolling releases, we branch out from the main
>>>> version tag and do a maintenance release that leaves on, assuming it
>>>> can't get merged back into master.
>>>>
>>>>>
>>>>>> -a clean way to merge features and bug fixes
>>>>>
>>>>> +1
>>>>>
>>>>>> -a clean way to create a release that should reduce our time to release
>>>>>
>>>>> +1 Although I still think that slowness for our release was mostly
>>>>> caused
>>>>> by the last minute regression bugs caused by missing quality control +
>>>>> lack of CI.
>>>>
>>>> True, but it is also due to the fact that we start a release branch from
>>>> a messy master where regressions happen.
>>>>
>>>>> This new way would just take off the load from RM by
>>>>> eliminating endless cherry-picking.
>>>>>
>>>>
>>>> I would love to have a workflow where the RM has a very clean job (pick
>>>> the features that should be in the release, pick the hot fixes release).
>>>> It should just be a series of git merge and that's it.
>>>>
>>>> master branch is only released software, only touched by RMs
>>>>
>>>> released branches only touched by RMs
>>>>
>>>> develop shared but merges happen only after successful CI and guarantee
>>>> of no regressions.
>>>>
>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the cloud
>> <http://solidfire.com/solution/overview/?video=play>*™*
>
> 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] git workflow

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

Hi all,

Let’s end this discussion thread.

I asked Vincent (nvie) and some friends from google and facebook on this and all of them recommended that this is not for us; then I read the whole thread again without prejudice or ego and I think it’s not for us though we should pick up couple of good ideas from it:

- git-flow was designed for only “forward” releases
- git-flow does not support multiple concurrent and non-chronological releases/support very well (no nvie documentation on how to do that)

Instead, if you’re interested on such topic I started a proposal (inspired by couple of workflows) on solving cherry-picking issue by adapting our release/master workflow please have a look on that. Some good reads on other git workflows we can get ideas from;

http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows (my new proposal uses this idea)
https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html (read this at least once)

PS. Let me know privately if you want me to forward you Vincent’s email

On 07-Aug-2014, at 11:52 pm, Mike Tutkowski <mi...@solidfire.com> wrote:

> This is what I was wondering about, as well. It seems all of our 'master'
> problems become 'develop' problems.
>
> I do like the idea of merging versus cherry picking (as a general rule),
> though.
>
>
> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
>> Sebastian, addressing the following comment of yours
>>
>>
>> "The main issue with master right now is that it moves really fast as a
>> shared branch, people merge features without warning, we see regressions
>> etc..
>> By the time we release a major version, master has moved so much that it
>> feels like starting over with the next release. It's almost as if we are
>> forking our own software. CI alone (even if it were really good) will not
>> fix this.”
>>
>>
>> You will still have this problem. You cut the next release branch from the
>> *develop branch, not from master. And the *develop branch will move with
>> the same pace as the old master, after the release branch is cut. So
>> “master moving really fast” problem would become “develop moving really
>> fast”.
>>
>> The problems you’ve mentioned - people merge features without warning, we
>> see regressions - can be fixed only with automation in place and the
>> requirement to run this automation (CI/BVT) before the merge is done.
>> Otherwise you are just shifting all existing problems from master to
>> develop.
>>
>>
>> -Alena.
>>
>>
>>
>> On 8/7/14, 2:15 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>
>>>
>>> On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>>> <Al...@citrix.com> wrote:
>>>
>>>>
>>>>
>>>> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>>>>
>>>>>
>>>>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>
>>>>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <ru...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>
>>>>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>>>>>>> <Al...@citrix.com> wrote:
>>>>>>>>> Edison, thank you for raising the concern about the BVT/CI.
>>>>>>>>> Somebody
>>>>>>>>> mentioned earlier that we should separate git workflow
>>>>>>>>> implementation from
>>>>>>>>> the CI effort, but I do think we have to do in in conjunction.
>>>>>>>>> Otherwise
>>>>>>>>> what is the point in introducing staging/develop branch? If there
>>>>>>>>> is
>>>>>>>>> no
>>>>>>>>> daily automation run verifying all the code merged from
>>>>>>>>> hotFixes/feature
>>>>>>>>> branches (and possibly reverting wrong checkins), we can as well
>>>>>>>>> merge the
>>>>>>>>> code directly to master.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes! - please.
>>>>>>>> Doing this without CI as a gating factor buys us very little.
>>>>>>>>
>>>>>>>> --David
>>>>>>>
>>>>>>> David, can you clarify. Are you going to be against any change of git
>>>>>>> workflow until we get CI/BVT in place ?
>>>>>>>
>>>>>>
>>>>>> No, please don't take it that way.
>>>>>> I understand Leo's point about Cherry-picking being for fruit, and not
>>>>>> code. But, I don't think that the workflow changes I've seen proposed
>>>>>> affect quality. So shifting for quality's sake doesn't make a lot of
>>>>>> sense in my mind. They could be a component of fixing the quality
>>>>>> problem.
>>>>>>
>>>>>> --David
>>>>>
>>>>> Agreed, the changes don't affect quality but should support a CI infra
>>>>> that helps improves quality.
>>>>>
>>>>> I do think the changes provide
>>>>>
>>>>> -a stable master that represent released software
>>>>
>>>>
>>>> You can always look at the latest release branch to get it,
>>>
>>> Yes I know how to get to the latest released software.
>>>
>>> I actually don't have good answers for your questions but I think Nate's
>>> email (couple emails back) answers a lot of them.
>>>
>>>> as we are
>>>> planning to keep them around to support maintenance. From the developer
>>>> stand point, I would be more interested in getting the latest stable
>>>> code,
>>>> not the latest stable release.
>>>
>>> I think that's fine from a developer standpoint. I tend to look at things
>>> from a user standpoint.
>>> I think a basic user who wants to check out source (because he builds his
>>> own packages), would like to checkout the latest master to get the latest
>>> released software (not everybody software projects works like this of
>>> course).
>>>
>>> The main issue with master right now is that it moves really fast as a
>>> shared branch, people merge features without warning, we see regressions
>>> etc..
>>> By the time we release a major version, master has moved so much that it
>>> feels like starting over with the next release. It's almost as if we are
>>> forking our own software. CI alone (even if it were really good) will not
>>> fix this.
>>>
>>> So assuming we have CI in place, we do need a better workflow (let's not
>>> call it gitflow anymore) to self-discipline ourselves.
>>>
>>>>
>>>> I don¹t see the use of stable master branch during the release either,
>>>> as
>>>> it reflects already released versions of the CS. And you never cut the
>>>> release from the stable master branch; you do cut it from *develop -
>>>> that¹s what the git workflow suggests.
>>>
>>> That's where our use case differs from gitflow. Several folks have
>>> already mentioned that we are going to deviate from pure gitflow, it is
>>> just a nice framework to start creating our own workflow.
>>>
>>> Personally, I would love to cut the release branches from master (instead
>>> of develop). that way you always start from a clean slate, instead of the
>>> mess with start with right now.
>>>
>>> Say develop is more of a staging branch, as you have advocated. We can
>>> run CI/BVT on that branch (we should run it everywhere…but anyway) and
>>> make sure features merged in work as advertized.
>>>
>>> When time comes to release, we cut from master and merge the features
>>> that have been merged in develop already, then go into QA, merge the
>>> fixes back to develop etc….when released, we merge back to master.
>>>
>>> If/since we don't do rolling releases, we branch out from the main
>>> version tag and do a maintenance release that leaves on, assuming it
>>> can't get merged back into master.
>>>
>>>>
>>>>> -a clean way to merge features and bug fixes
>>>>
>>>> +1
>>>>
>>>>> -a clean way to create a release that should reduce our time to release
>>>>
>>>> +1 Although I still think that slowness for our release was mostly
>>>> caused
>>>> by the last minute regression bugs caused by missing quality control +
>>>> lack of CI.
>>>
>>> True, but it is also due to the fact that we start a release branch from
>>> a messy master where regressions happen.
>>>
>>>> This new way would just take off the load from RM by
>>>> eliminating endless cherry-picking.
>>>>
>>>
>>> I would love to have a workflow where the RM has a very clean job (pick
>>> the features that should be in the release, pick the hot fixes release).
>>> It should just be a series of git merge and that's it.
>>>
>>> master branch is only released software, only touched by RMs
>>>
>>> released branches only touched by RMs
>>>
>>> develop shared but merges happen only after successful CI and guarantee
>>> of no regressions.
>>>
>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*

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] git workflow

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

3 it should be made in a hotfix/4.4-<jira number> branch and reviewed
and merged from there

On Fri, Aug 8, 2014 at 9:16 AM, Rajani Karuturi <ra...@apache.org> wrote:
> A git workflow change will not solve the quality problems we have. They
> have to be dealt with independently. Just because we are changing the way
> we commit the code doesnt mean we wont have any quality issues introduced
> by the commits. It just ensures that issues/fixes are properly transferred
> to the next releases and we have a better way to understand where all the
> issue is fixed/or first seen.
>
> Yes the problems we have on master will shift to develop branch. But the
> workflow change is not intended to solve them. It cannot tell us how to
> write bug free code/ inform there are bugs.
>
> What is the problem with having stable master branch pointing to latest
> release? Any user/developer who wants to try out cloudstack, can just
> checkout code and deploy and gets a nice first impression. Without having
> to look at what is the latest release whether 4.4 is stable or 4.3.1 or
> 4.2. In my opinion thats a big advantage.
> At this point, we arent sure that if we pass BVT, then we can release the
> code. Though that can be the first step( See 4.4 for example.)
> When we reach such a point, then we can merge stuff to master as soon as
> they pass BVT. But, until then it has to be the released code in my opinion.
>
> Following git-flow doesnt mean we have to follow each and every aspect of
> it. Lets start with it and make any amendments as required to fit our way.
> As the git-flow says a fix from support branch should reach master through
> hotfix doesnt mean we have to follow the same. If you feel they havent
> diverged a lot and can be merged, that can be merged. The important thing
> being, if the bug is relevant for the next release, it should go to
> develop/master.
>
> Also, as leo already said earlier, cherry-picking in itself is not the
> devil. The tool exists for a reason and it has to be used when required.
> For example when you are backporting a fix from minor release(which has
> diverged a lot from master and doesn't make sense to merge)
>
>
> (The discussion[s] has been so long that I feel like I am repeating my self)
>
> we haven't planned 4.5 yet though the code freeze date is long gone. We
> don't have RM for it. We have to release 4.4.1 immediately(It is a hotfix).
> This discussion is masking everything else.
>
> As we all agree that we have to solve the cherry-picking issue we have, can
> we focus on that please? We can get back to staging/develop branch later.
> CI/BVT as and when they are available. step-by-step.
>
> Let us use our current model with minor change that no cherry-picking after
> the release branch is created. Lets just work on the release branch
> directly.
> 1. it should only contain bug fixes and any bug going to the branch should
> be discussed/notified on the dev list(preferably before you work on it).
> 2. It should be merged/committed to the release branch only after it passes
> BVT(whether you run it locally or let jenkins run it by creating a
> hotfix/CS-* branch).
>
> thoughts?
>
>
> On Fri, Aug 8, 2014 at 3:22 AM, Mike Tutkowski <mike.tutkowski@solidfire.com
>> wrote:
>
>> This is what I was wondering about, as well. It seems all of our 'master'
>> problems become 'develop' problems.
>>
>> I do like the idea of merging versus cherry picking (as a general rule),
>> though.
>>
>>
>> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
>> Alena.Prokharchyk@citrix.com> wrote:
>>
>> > Sebastian, addressing the following comment of yours
>> >
>> >
>> > "The main issue with master right now is that it moves really fast as a
>> > shared branch, people merge features without warning, we see regressions
>> > etc..
>> > By the time we release a major version, master has moved so much that it
>> > feels like starting over with the next release. It's almost as if we are
>> > forking our own software. CI alone (even if it were really good) will not
>> > fix this.”
>> >
>> >
>> > You will still have this problem. You cut the next release branch from
>> the
>> > *develop branch, not from master. And the *develop branch will move with
>> > the same pace as the old master, after the release branch is cut. So
>> > “master moving really fast” problem would become “develop moving really
>> > fast”.
>> >
>> > The problems you’ve mentioned - people merge features without warning, we
>> > see regressions - can be fixed only with automation in place and the
>> > requirement to run this automation (CI/BVT) before the merge is done.
>> > Otherwise you are just shifting all existing problems from master to
>> > develop.
>> >
>> >
>> > -Alena.
>> >
>> >
>> >
>> > On 8/7/14, 2:15 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>> >
>> > >
>> > >On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>> > ><Al...@citrix.com> wrote:
>> > >
>> > >>
>> > >>
>> > >> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>> > >>
>> > >>>
>> > >>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:
>> > >>>
>> > >>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <
>> runseb@gmail.com>
>> > >>>> wrote:
>> > >>>>>
>> > >>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
>> > >>>>>
>> > >>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>> > >>>>>> <Al...@citrix.com> wrote:
>> > >>>>>>> Edison, thank you for raising the concern about the BVT/CI.
>> > >>>>>>>Somebody
>> > >>>>>>> mentioned earlier that we should separate git workflow
>> > >>>>>>> implementation from
>> > >>>>>>> the CI effort, but I do think we have to do in in conjunction.
>> > >>>>>>> Otherwise
>> > >>>>>>> what is the point in introducing staging/develop branch? If there
>> > >>>>>>>is
>> > >>>>>>> no
>> > >>>>>>> daily automation run verifying all the code merged from
>> > >>>>>>> hotFixes/feature
>> > >>>>>>> branches (and possibly reverting wrong checkins), we can as well
>> > >>>>>>> merge the
>> > >>>>>>> code directly to master.
>> > >>>>>>>
>> > >>>>>>
>> > >>>>>> Yes! - please.
>> > >>>>>> Doing this without CI as a gating factor buys us very little.
>> > >>>>>>
>> > >>>>>> --David
>> > >>>>>
>> > >>>>> David, can you clarify. Are you going to be against any change of
>> git
>> > >>>>> workflow until we get CI/BVT in place ?
>> > >>>>>
>> > >>>>
>> > >>>> No, please don't take it that way.
>> > >>>> I understand Leo's point about Cherry-picking being for fruit, and
>> not
>> > >>>> code. But, I don't think that the workflow changes I've seen
>> proposed
>> > >>>> affect quality. So shifting for quality's sake doesn't make a lot of
>> > >>>> sense in my mind. They could be a component of fixing the quality
>> > >>>> problem.
>> > >>>>
>> > >>>> --David
>> > >>>
>> > >>> Agreed, the changes don't affect quality but should support a CI
>> infra
>> > >>> that helps improves quality.
>> > >>>
>> > >>> I do think the changes provide
>> > >>>
>> > >>> -a stable master that represent released software
>> > >>
>> > >>
>> > >> You can always look at the latest release branch to get it,
>> > >
>> > >Yes I know how to get to the latest released software.
>> > >
>> > >I actually don't have good answers for your questions but I think Nate's
>> > >email (couple emails back) answers a lot of them.
>> > >
>> > >> as we are
>> > >> planning to keep them around to support maintenance. From the
>> developer
>> > >> stand point, I would be more interested in getting the latest stable
>> > >>code,
>> > >> not the latest stable release.
>> > >
>> > >I think that's fine from a developer standpoint. I tend to look at
>> things
>> > >from a user standpoint.
>> > >I think a basic user who wants to check out source (because he builds
>> his
>> > >own packages), would like to checkout the latest master to get the
>> latest
>> > >released software (not everybody software projects works like this of
>> > >course).
>> > >
>> > >The main issue with master right now is that it moves really fast as a
>> > >shared branch, people merge features without warning, we see regressions
>> > >etc..
>> > >By the time we release a major version, master has moved so much that it
>> > >feels like starting over with the next release. It's almost as if we are
>> > >forking our own software. CI alone (even if it were really good) will
>> not
>> > >fix this.
>> > >
>> > >So assuming we have CI in place, we do need a better workflow (let's not
>> > >call it gitflow anymore) to self-discipline ourselves.
>> > >
>> > >>
>> > >> I don¹t see the use of stable master branch during the release either,
>> > >>as
>> > >> it reflects already released versions of the CS. And you never cut the
>> > >> release from the stable master branch; you do cut it from *develop -
>> > >> that¹s what the git workflow suggests.
>> > >
>> > >That's where our use case differs from gitflow. Several folks have
>> > >already mentioned that we are going to deviate from pure gitflow, it is
>> > >just a nice framework to start creating our own workflow.
>> > >
>> > >Personally, I would love to cut the release branches from master
>> (instead
>> > >of develop). that way you always start from a clean slate, instead of
>> the
>> > >mess with start with right now.
>> > >
>> > >Say develop is more of a staging branch, as you have advocated. We can
>> > >run CI/BVT on that branch (we should run it everywhere…but anyway) and
>> > >make sure features merged in work as advertized.
>> > >
>> > >When time comes to release, we cut from master and merge the features
>> > >that have been merged in develop already, then go into QA, merge the
>> > >fixes back to develop etc….when released, we merge back to master.
>> > >
>> > >If/since we don't do rolling releases, we branch out from the main
>> > >version tag and do a maintenance release that leaves on, assuming it
>> > >can't get merged back into master.
>> > >
>> > >>
>> > >>> -a clean way to merge features and bug fixes
>> > >>
>> > >> +1
>> > >>
>> > >>> -a clean way to create a release that should reduce our time to
>> release
>> > >>
>> > >> +1 Although I still think that slowness for our release was mostly
>> > >>caused
>> > >> by the last minute regression bugs caused by missing quality control +
>> > >> lack of CI.
>> > >
>> > >True, but it is also due to the fact that we start a release branch from
>> > >a messy master where regressions happen.
>> > >
>> > >> This new way would just take off the load from RM by
>> > >> eliminating endless cherry-picking.
>> > >>
>> > >
>> > >I would love to have a workflow where the RM has a very clean job (pick
>> > >the features that should be in the release, pick the hot fixes release).
>> > >It should just be a series of git merge and that's it.
>> > >
>> > >master branch is only released software, only touched by RMs
>> > >
>> > >released branches only touched by RMs
>> > >
>> > >develop shared but merges happen only after successful CI and guarantee
>> > >of no regressions.
>> > >
>> > >>
>> > >>>
>> > >>
>> > >
>> >
>> >
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the cloud
>> <http://solidfire.com/solution/overview/?video=play>*™*
>>
>
>
>
> --
> ~Rajani



-- 
Daan

Re: [VOTE] git workflow

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

A git workflow change will not solve the quality problems we have. They
have to be dealt with independently. Just because we are changing the way
we commit the code doesnt mean we wont have any quality issues introduced
by the commits. It just ensures that issues/fixes are properly transferred
to the next releases and we have a better way to understand where all the
issue is fixed/or first seen.

Yes the problems we have on master will shift to develop branch. But the
workflow change is not intended to solve them. It cannot tell us how to
write bug free code/ inform there are bugs.

What is the problem with having stable master branch pointing to latest
release? Any user/developer who wants to try out cloudstack, can just
checkout code and deploy and gets a nice first impression. Without having
to look at what is the latest release whether 4.4 is stable or 4.3.1 or
4.2. In my opinion thats a big advantage.
At this point, we arent sure that if we pass BVT, then we can release the
code. Though that can be the first step( See 4.4 for example.)
When we reach such a point, then we can merge stuff to master as soon as
they pass BVT. But, until then it has to be the released code in my opinion.

Following git-flow doesnt mean we have to follow each and every aspect of
it. Lets start with it and make any amendments as required to fit our way.
As the git-flow says a fix from support branch should reach master through
hotfix doesnt mean we have to follow the same. If you feel they havent
diverged a lot and can be merged, that can be merged. The important thing
being, if the bug is relevant for the next release, it should go to
develop/master.

Also, as leo already said earlier, cherry-picking in itself is not the
devil. The tool exists for a reason and it has to be used when required.
For example when you are backporting a fix from minor release(which has
diverged a lot from master and doesn't make sense to merge)


(The discussion[s] has been so long that I feel like I am repeating my self)

we haven't planned 4.5 yet though the code freeze date is long gone. We
don't have RM for it. We have to release 4.4.1 immediately(It is a hotfix).
This discussion is masking everything else.

As we all agree that we have to solve the cherry-picking issue we have, can
we focus on that please? We can get back to staging/develop branch later.
CI/BVT as and when they are available. step-by-step.

Let us use our current model with minor change that no cherry-picking after
the release branch is created. Lets just work on the release branch
directly.
1. it should only contain bug fixes and any bug going to the branch should
be discussed/notified on the dev list(preferably before you work on it).
2. It should be merged/committed to the release branch only after it passes
BVT(whether you run it locally or let jenkins run it by creating a
hotfix/CS-* branch).

thoughts?


On Fri, Aug 8, 2014 at 3:22 AM, Mike Tutkowski <mike.tutkowski@solidfire.com
> wrote:

> This is what I was wondering about, as well. It seems all of our 'master'
> problems become 'develop' problems.
>
> I do like the idea of merging versus cherry picking (as a general rule),
> though.
>
>
> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
> > Sebastian, addressing the following comment of yours
> >
> >
> > "The main issue with master right now is that it moves really fast as a
> > shared branch, people merge features without warning, we see regressions
> > etc..
> > By the time we release a major version, master has moved so much that it
> > feels like starting over with the next release. It's almost as if we are
> > forking our own software. CI alone (even if it were really good) will not
> > fix this.”
> >
> >
> > You will still have this problem. You cut the next release branch from
> the
> > *develop branch, not from master. And the *develop branch will move with
> > the same pace as the old master, after the release branch is cut. So
> > “master moving really fast” problem would become “develop moving really
> > fast”.
> >
> > The problems you’ve mentioned - people merge features without warning, we
> > see regressions - can be fixed only with automation in place and the
> > requirement to run this automation (CI/BVT) before the merge is done.
> > Otherwise you are just shifting all existing problems from master to
> > develop.
> >
> >
> > -Alena.
> >
> >
> >
> > On 8/7/14, 2:15 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
> >
> > >
> > >On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
> > ><Al...@citrix.com> wrote:
> > >
> > >>
> > >>
> > >> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
> > >>
> > >>>
> > >>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:
> > >>>
> > >>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <
> runseb@gmail.com>
> > >>>> wrote:
> > >>>>>
> > >>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
> > >>>>>
> > >>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
> > >>>>>> <Al...@citrix.com> wrote:
> > >>>>>>> Edison, thank you for raising the concern about the BVT/CI.
> > >>>>>>>Somebody
> > >>>>>>> mentioned earlier that we should separate git workflow
> > >>>>>>> implementation from
> > >>>>>>> the CI effort, but I do think we have to do in in conjunction.
> > >>>>>>> Otherwise
> > >>>>>>> what is the point in introducing staging/develop branch? If there
> > >>>>>>>is
> > >>>>>>> no
> > >>>>>>> daily automation run verifying all the code merged from
> > >>>>>>> hotFixes/feature
> > >>>>>>> branches (and possibly reverting wrong checkins), we can as well
> > >>>>>>> merge the
> > >>>>>>> code directly to master.
> > >>>>>>>
> > >>>>>>
> > >>>>>> Yes! - please.
> > >>>>>> Doing this without CI as a gating factor buys us very little.
> > >>>>>>
> > >>>>>> --David
> > >>>>>
> > >>>>> David, can you clarify. Are you going to be against any change of
> git
> > >>>>> workflow until we get CI/BVT in place ?
> > >>>>>
> > >>>>
> > >>>> No, please don't take it that way.
> > >>>> I understand Leo's point about Cherry-picking being for fruit, and
> not
> > >>>> code. But, I don't think that the workflow changes I've seen
> proposed
> > >>>> affect quality. So shifting for quality's sake doesn't make a lot of
> > >>>> sense in my mind. They could be a component of fixing the quality
> > >>>> problem.
> > >>>>
> > >>>> --David
> > >>>
> > >>> Agreed, the changes don't affect quality but should support a CI
> infra
> > >>> that helps improves quality.
> > >>>
> > >>> I do think the changes provide
> > >>>
> > >>> -a stable master that represent released software
> > >>
> > >>
> > >> You can always look at the latest release branch to get it,
> > >
> > >Yes I know how to get to the latest released software.
> > >
> > >I actually don't have good answers for your questions but I think Nate's
> > >email (couple emails back) answers a lot of them.
> > >
> > >> as we are
> > >> planning to keep them around to support maintenance. From the
> developer
> > >> stand point, I would be more interested in getting the latest stable
> > >>code,
> > >> not the latest stable release.
> > >
> > >I think that's fine from a developer standpoint. I tend to look at
> things
> > >from a user standpoint.
> > >I think a basic user who wants to check out source (because he builds
> his
> > >own packages), would like to checkout the latest master to get the
> latest
> > >released software (not everybody software projects works like this of
> > >course).
> > >
> > >The main issue with master right now is that it moves really fast as a
> > >shared branch, people merge features without warning, we see regressions
> > >etc..
> > >By the time we release a major version, master has moved so much that it
> > >feels like starting over with the next release. It's almost as if we are
> > >forking our own software. CI alone (even if it were really good) will
> not
> > >fix this.
> > >
> > >So assuming we have CI in place, we do need a better workflow (let's not
> > >call it gitflow anymore) to self-discipline ourselves.
> > >
> > >>
> > >> I don¹t see the use of stable master branch during the release either,
> > >>as
> > >> it reflects already released versions of the CS. And you never cut the
> > >> release from the stable master branch; you do cut it from *develop -
> > >> that¹s what the git workflow suggests.
> > >
> > >That's where our use case differs from gitflow. Several folks have
> > >already mentioned that we are going to deviate from pure gitflow, it is
> > >just a nice framework to start creating our own workflow.
> > >
> > >Personally, I would love to cut the release branches from master
> (instead
> > >of develop). that way you always start from a clean slate, instead of
> the
> > >mess with start with right now.
> > >
> > >Say develop is more of a staging branch, as you have advocated. We can
> > >run CI/BVT on that branch (we should run it everywhere…but anyway) and
> > >make sure features merged in work as advertized.
> > >
> > >When time comes to release, we cut from master and merge the features
> > >that have been merged in develop already, then go into QA, merge the
> > >fixes back to develop etc….when released, we merge back to master.
> > >
> > >If/since we don't do rolling releases, we branch out from the main
> > >version tag and do a maintenance release that leaves on, assuming it
> > >can't get merged back into master.
> > >
> > >>
> > >>> -a clean way to merge features and bug fixes
> > >>
> > >> +1
> > >>
> > >>> -a clean way to create a release that should reduce our time to
> release
> > >>
> > >> +1 Although I still think that slowness for our release was mostly
> > >>caused
> > >> by the last minute regression bugs caused by missing quality control +
> > >> lack of CI.
> > >
> > >True, but it is also due to the fact that we start a release branch from
> > >a messy master where regressions happen.
> > >
> > >> This new way would just take off the load from RM by
> > >> eliminating endless cherry-picking.
> > >>
> > >
> > >I would love to have a workflow where the RM has a very clean job (pick
> > >the features that should be in the release, pick the hot fixes release).
> > >It should just be a series of git merge and that's it.
> > >
> > >master branch is only released software, only touched by RMs
> > >
> > >released branches only touched by RMs
> > >
> > >develop shared but merges happen only after successful CI and guarantee
> > >of no regressions.
> > >
> > >>
> > >>>
> > >>
> > >
> >
> >
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*
>



-- 
~Rajani

Re: [VOTE] git workflow

[Mike Tutkowski <mi...@solidfire.com>]

This is what I was wondering about, as well. It seems all of our 'master'
problems become 'develop' problems.

I do like the idea of merging versus cherry picking (as a general rule),
though.


On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> Sebastian, addressing the following comment of yours
>
>
> "The main issue with master right now is that it moves really fast as a
> shared branch, people merge features without warning, we see regressions
> etc..
> By the time we release a major version, master has moved so much that it
> feels like starting over with the next release. It's almost as if we are
> forking our own software. CI alone (even if it were really good) will not
> fix this.”
>
>
> You will still have this problem. You cut the next release branch from the
> *develop branch, not from master. And the *develop branch will move with
> the same pace as the old master, after the release branch is cut. So
> “master moving really fast” problem would become “develop moving really
> fast”.
>
> The problems you’ve mentioned - people merge features without warning, we
> see regressions - can be fixed only with automation in place and the
> requirement to run this automation (CI/BVT) before the merge is done.
> Otherwise you are just shifting all existing problems from master to
> develop.
>
>
> -Alena.
>
>
>
> On 8/7/14, 2:15 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>
> >
> >On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
> ><Al...@citrix.com> wrote:
> >
> >>
> >>
> >> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
> >>
> >>>
> >>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:
> >>>
> >>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <ru...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
> >>>>>
> >>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
> >>>>>> <Al...@citrix.com> wrote:
> >>>>>>> Edison, thank you for raising the concern about the BVT/CI.
> >>>>>>>Somebody
> >>>>>>> mentioned earlier that we should separate git workflow
> >>>>>>> implementation from
> >>>>>>> the CI effort, but I do think we have to do in in conjunction.
> >>>>>>> Otherwise
> >>>>>>> what is the point in introducing staging/develop branch? If there
> >>>>>>>is
> >>>>>>> no
> >>>>>>> daily automation run verifying all the code merged from
> >>>>>>> hotFixes/feature
> >>>>>>> branches (and possibly reverting wrong checkins), we can as well
> >>>>>>> merge the
> >>>>>>> code directly to master.
> >>>>>>>
> >>>>>>
> >>>>>> Yes! - please.
> >>>>>> Doing this without CI as a gating factor buys us very little.
> >>>>>>
> >>>>>> --David
> >>>>>
> >>>>> David, can you clarify. Are you going to be against any change of git
> >>>>> workflow until we get CI/BVT in place ?
> >>>>>
> >>>>
> >>>> No, please don't take it that way.
> >>>> I understand Leo's point about Cherry-picking being for fruit, and not
> >>>> code. But, I don't think that the workflow changes I've seen proposed
> >>>> affect quality. So shifting for quality's sake doesn't make a lot of
> >>>> sense in my mind. They could be a component of fixing the quality
> >>>> problem.
> >>>>
> >>>> --David
> >>>
> >>> Agreed, the changes don't affect quality but should support a CI infra
> >>> that helps improves quality.
> >>>
> >>> I do think the changes provide
> >>>
> >>> -a stable master that represent released software
> >>
> >>
> >> You can always look at the latest release branch to get it,
> >
> >Yes I know how to get to the latest released software.
> >
> >I actually don't have good answers for your questions but I think Nate's
> >email (couple emails back) answers a lot of them.
> >
> >> as we are
> >> planning to keep them around to support maintenance. From the developer
> >> stand point, I would be more interested in getting the latest stable
> >>code,
> >> not the latest stable release.
> >
> >I think that's fine from a developer standpoint. I tend to look at things
> >from a user standpoint.
> >I think a basic user who wants to check out source (because he builds his
> >own packages), would like to checkout the latest master to get the latest
> >released software (not everybody software projects works like this of
> >course).
> >
> >The main issue with master right now is that it moves really fast as a
> >shared branch, people merge features without warning, we see regressions
> >etc..
> >By the time we release a major version, master has moved so much that it
> >feels like starting over with the next release. It's almost as if we are
> >forking our own software. CI alone (even if it were really good) will not
> >fix this.
> >
> >So assuming we have CI in place, we do need a better workflow (let's not
> >call it gitflow anymore) to self-discipline ourselves.
> >
> >>
> >> I don¹t see the use of stable master branch during the release either,
> >>as
> >> it reflects already released versions of the CS. And you never cut the
> >> release from the stable master branch; you do cut it from *develop -
> >> that¹s what the git workflow suggests.
> >
> >That's where our use case differs from gitflow. Several folks have
> >already mentioned that we are going to deviate from pure gitflow, it is
> >just a nice framework to start creating our own workflow.
> >
> >Personally, I would love to cut the release branches from master (instead
> >of develop). that way you always start from a clean slate, instead of the
> >mess with start with right now.
> >
> >Say develop is more of a staging branch, as you have advocated. We can
> >run CI/BVT on that branch (we should run it everywhere…but anyway) and
> >make sure features merged in work as advertized.
> >
> >When time comes to release, we cut from master and merge the features
> >that have been merged in develop already, then go into QA, merge the
> >fixes back to develop etc….when released, we merge back to master.
> >
> >If/since we don't do rolling releases, we branch out from the main
> >version tag and do a maintenance release that leaves on, assuming it
> >can't get merged back into master.
> >
> >>
> >>> -a clean way to merge features and bug fixes
> >>
> >> +1
> >>
> >>> -a clean way to create a release that should reduce our time to release
> >>
> >> +1 Although I still think that slowness for our release was mostly
> >>caused
> >> by the last minute regression bugs caused by missing quality control +
> >> lack of CI.
> >
> >True, but it is also due to the fact that we start a release branch from
> >a messy master where regressions happen.
> >
> >> This new way would just take off the load from RM by
> >> eliminating endless cherry-picking.
> >>
> >
> >I would love to have a workflow where the RM has a very clean job (pick
> >the features that should be in the release, pick the hot fixes release).
> >It should just be a series of git merge and that's it.
> >
> >master branch is only released software, only touched by RMs
> >
> >released branches only touched by RMs
> >
> >develop shared but merges happen only after successful CI and guarantee
> >of no regressions.
> >
> >>
> >>>
> >>
> >
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Sebastian, addressing the following comment of yours


"The main issue with master right now is that it moves really fast as a
shared branch, people merge features without warning, we see regressions
etc..
By the time we release a major version, master has moved so much that it
feels like starting over with the next release. It's almost as if we are
forking our own software. CI alone (even if it were really good) will not
fix this.”


You will still have this problem. You cut the next release branch from the
*develop branch, not from master. And the *develop branch will move with
the same pace as the old master, after the release branch is cut. So
“master moving really fast” problem would become “develop moving really
fast”. 

The problems you’ve mentioned - people merge features without warning, we
see regressions - can be fixed only with automation in place and the
requirement to run this automation (CI/BVT) before the merge is done.
Otherwise you are just shifting all existing problems from master to
develop. 


-Alena.



On 8/7/14, 2:15 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:

>
>On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
><Al...@citrix.com> wrote:
>
>> 
>> 
>> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>> 
>>> 
>>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:
>>> 
>>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <ru...@gmail.com>
>>>> wrote:
>>>>> 
>>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
>>>>> 
>>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>>>>> <Al...@citrix.com> wrote:
>>>>>>> Edison, thank you for raising the concern about the BVT/CI.
>>>>>>>Somebody
>>>>>>> mentioned earlier that we should separate git workflow
>>>>>>> implementation from
>>>>>>> the CI effort, but I do think we have to do in in conjunction.
>>>>>>> Otherwise
>>>>>>> what is the point in introducing staging/develop branch? If there
>>>>>>>is
>>>>>>> no
>>>>>>> daily automation run verifying all the code merged from
>>>>>>> hotFixes/feature
>>>>>>> branches (and possibly reverting wrong checkins), we can as well
>>>>>>> merge the
>>>>>>> code directly to master.
>>>>>>> 
>>>>>> 
>>>>>> Yes! - please.
>>>>>> Doing this without CI as a gating factor buys us very little.
>>>>>> 
>>>>>> --David
>>>>> 
>>>>> David, can you clarify. Are you going to be against any change of git
>>>>> workflow until we get CI/BVT in place ?
>>>>> 
>>>> 
>>>> No, please don't take it that way.
>>>> I understand Leo's point about Cherry-picking being for fruit, and not
>>>> code. But, I don't think that the workflow changes I've seen proposed
>>>> affect quality. So shifting for quality's sake doesn't make a lot of
>>>> sense in my mind. They could be a component of fixing the quality
>>>> problem.
>>>> 
>>>> --David
>>> 
>>> Agreed, the changes don't affect quality but should support a CI infra
>>> that helps improves quality.
>>> 
>>> I do think the changes provide
>>> 
>>> -a stable master that represent released software
>> 
>> 
>> You can always look at the latest release branch to get it,
>
>Yes I know how to get to the latest released software.
>
>I actually don't have good answers for your questions but I think Nate's
>email (couple emails back) answers a lot of them.
>
>> as we are
>> planning to keep them around to support maintenance. From the developer
>> stand point, I would be more interested in getting the latest stable
>>code,
>> not the latest stable release.
>
>I think that's fine from a developer standpoint. I tend to look at things
>from a user standpoint.
>I think a basic user who wants to check out source (because he builds his
>own packages), would like to checkout the latest master to get the latest
>released software (not everybody software projects works like this of
>course).
>
>The main issue with master right now is that it moves really fast as a
>shared branch, people merge features without warning, we see regressions
>etc..
>By the time we release a major version, master has moved so much that it
>feels like starting over with the next release. It's almost as if we are
>forking our own software. CI alone (even if it were really good) will not
>fix this.
>
>So assuming we have CI in place, we do need a better workflow (let's not
>call it gitflow anymore) to self-discipline ourselves.
>
>> 
>> I don¹t see the use of stable master branch during the release either,
>>as
>> it reflects already released versions of the CS. And you never cut the
>> release from the stable master branch; you do cut it from *develop -
>> that¹s what the git workflow suggests.
>
>That's where our use case differs from gitflow. Several folks have
>already mentioned that we are going to deviate from pure gitflow, it is
>just a nice framework to start creating our own workflow.
>
>Personally, I would love to cut the release branches from master (instead
>of develop). that way you always start from a clean slate, instead of the
>mess with start with right now.
>
>Say develop is more of a staging branch, as you have advocated. We can
>run CI/BVT on that branch (we should run it everywhere…but anyway) and
>make sure features merged in work as advertized.
>
>When time comes to release, we cut from master and merge the features
>that have been merged in develop already, then go into QA, merge the
>fixes back to develop etc….when released, we merge back to master.
>
>If/since we don't do rolling releases, we branch out from the main
>version tag and do a maintenance release that leaves on, assuming it
>can't get merged back into master.
>
>> 
>>> -a clean way to merge features and bug fixes
>> 
>> +1
>> 
>>> -a clean way to create a release that should reduce our time to release
>> 
>> +1 Although I still think that slowness for our release was mostly
>>caused
>> by the last minute regression bugs caused by missing quality control +
>> lack of CI.
>
>True, but it is also due to the fact that we start a release branch from
>a messy master where regressions happen.
>
>> This new way would just take off the load from RM by
>> eliminating endless cherry-picking.
>> 
>
>I would love to have a workflow where the RM has a very clean job (pick
>the features that should be in the release, pick the hot fixes release).
>It should just be a series of git merge and that's it.
>
>master branch is only released software, only touched by RMs
>
>released branches only touched by RMs
>
>develop shared but merges happen only after successful CI and guarantee
>of no regressions.
>
>> 
>>> 
>> 
>

Re: [VOTE] git workflow

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

On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk <Al...@citrix.com> wrote:

> 
> 
> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
> 
>> 
>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:
>> 
>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <ru...@gmail.com>
>>> wrote:
>>>> 
>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
>>>> 
>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>>>> <Al...@citrix.com> wrote:
>>>>>> Edison, thank you for raising the concern about the BVT/CI. Somebody
>>>>>> mentioned earlier that we should separate git workflow
>>>>>> implementation from
>>>>>> the CI effort, but I do think we have to do in in conjunction.
>>>>>> Otherwise
>>>>>> what is the point in introducing staging/develop branch? If there is
>>>>>> no
>>>>>> daily automation run verifying all the code merged from
>>>>>> hotFixes/feature
>>>>>> branches (and possibly reverting wrong checkins), we can as well
>>>>>> merge the
>>>>>> code directly to master.
>>>>>> 
>>>>> 
>>>>> Yes! - please.
>>>>> Doing this without CI as a gating factor buys us very little.
>>>>> 
>>>>> --David
>>>> 
>>>> David, can you clarify. Are you going to be against any change of git
>>>> workflow until we get CI/BVT in place ?
>>>> 
>>> 
>>> No, please don't take it that way.
>>> I understand Leo's point about Cherry-picking being for fruit, and not
>>> code. But, I don't think that the workflow changes I've seen proposed
>>> affect quality. So shifting for quality's sake doesn't make a lot of
>>> sense in my mind. They could be a component of fixing the quality
>>> problem.
>>> 
>>> --David
>> 
>> Agreed, the changes don't affect quality but should support a CI infra
>> that helps improves quality.
>> 
>> I do think the changes provide
>> 
>> -a stable master that represent released software
> 
> 
> You can always look at the latest release branch to get it,

Yes I know how to get to the latest released software.

I actually don't have good answers for your questions but I think Nate's email (couple emails back) answers a lot of them.

> as we are
> planning to keep them around to support maintenance. From the developer
> stand point, I would be more interested in getting the latest stable code,
> not the latest stable release.

I think that's fine from a developer standpoint. I tend to look at things from a user standpoint.
I think a basic user who wants to check out source (because he builds his own packages), would like to checkout the latest master to get the latest released software (not everybody software projects works like this of course).

The main issue with master right now is that it moves really fast as a shared branch, people merge features without warning, we see regressions etc..
By the time we release a major version, master has moved so much that it feels like starting over with the next release. It's almost as if we are forking our own software. CI alone (even if it were really good) will not fix this.

So assuming we have CI in place, we do need a better workflow (let's not call it gitflow anymore) to self-discipline ourselves.

> 
> I don¹t see the use of stable master branch during the release either, as
> it reflects already released versions of the CS. And you never cut the
> release from the stable master branch; you do cut it from *develop -
> that¹s what the git workflow suggests.

That's where our use case differs from gitflow. Several folks have already mentioned that we are going to deviate from pure gitflow, it is just a nice framework to start creating our own workflow.

Personally, I would love to cut the release branches from master (instead of develop). that way you always start from a clean slate, instead of the mess with start with right now.

Say develop is more of a staging branch, as you have advocated. We can run CI/BVT on that branch (we should run it everywhere…but anyway) and make sure features merged in work as advertized.

When time comes to release, we cut from master and merge the features that have been merged in develop already, then go into QA, merge the fixes back to develop etc….when released, we merge back to master.

If/since we don't do rolling releases, we branch out from the main version tag and do a maintenance release that leaves on, assuming it can't get merged back into master.

> 
>> -a clean way to merge features and bug fixes
> 
> +1
> 
>> -a clean way to create a release that should reduce our time to release
> 
> +1 Although I still think that slowness for our release was mostly caused
> by the last minute regression bugs caused by missing quality control +
> lack of CI.

True, but it is also due to the fact that we start a release branch from a messy master where regressions happen.

> This new way would just take off the load from RM by
> eliminating endless cherry-picking.
> 

I would love to have a workflow where the RM has a very clean job (pick the features that should be in the release, pick the hot fixes release). It should just be a series of git merge and that's it.

master branch is only released software, only touched by RMs

released branches only touched by RMs

develop shared but merges happen only after successful CI and guarantee of no regressions.

> 
>> 
> 

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

On 8/7/14, 1:42 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:

>
>On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:
>
>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <ru...@gmail.com>
>>wrote:
>>> 
>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
>>> 
>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>>> <Al...@citrix.com> wrote:
>>>>> Edison, thank you for raising the concern about the BVT/CI. Somebody
>>>>> mentioned earlier that we should separate git workflow
>>>>>implementation from
>>>>> the CI effort, but I do think we have to do in in conjunction.
>>>>>Otherwise
>>>>> what is the point in introducing staging/develop branch? If there is
>>>>>no
>>>>> daily automation run verifying all the code merged from
>>>>>hotFixes/feature
>>>>> branches (and possibly reverting wrong checkins), we can as well
>>>>>merge the
>>>>> code directly to master.
>>>>> 
>>>> 
>>>> Yes! - please.
>>>> Doing this without CI as a gating factor buys us very little.
>>>> 
>>>> --David
>>> 
>>> David, can you clarify. Are you going to be against any change of git
>>>workflow until we get CI/BVT in place ?
>>> 
>> 
>> No, please don't take it that way.
>> I understand Leo's point about Cherry-picking being for fruit, and not
>> code. But, I don't think that the workflow changes I've seen proposed
>> affect quality. So shifting for quality's sake doesn't make a lot of
>> sense in my mind. They could be a component of fixing the quality
>> problem.
>> 
>> --David
>
>Agreed, the changes don't affect quality but should support a CI infra
>that helps improves quality.
>
>I do think the changes provide
>
>-a stable master that represent released software


You can always look at the latest release branch to get it, as we are
planning to keep them around to support maintenance. From the developer
stand point, I would be more interested in getting the latest stable code,
not the latest stable release.

I don¹t see the use of stable master branch during the release either, as
it reflects already released versions of the CS. And you never cut the
release from the stable master branch; you do cut it from *develop -
that¹s what the git workflow suggests.




>-a clean way to merge features and bug fixes

+1

>-a clean way to create a release that should reduce our time to release

+1 Although I still think that slowness for our release was mostly caused
by the last minute regression bugs caused by missing quality control +
lack of CI. This new way would just take off the load from RM by
eliminating endless cherry-picking.


>

Re: [VOTE] git workflow

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

On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote:

> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>> 
>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
>> 
>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>> <Al...@citrix.com> wrote:
>>>> Edison, thank you for raising the concern about the BVT/CI. Somebody
>>>> mentioned earlier that we should separate git workflow implementation from
>>>> the CI effort, but I do think we have to do in in conjunction. Otherwise
>>>> what is the point in introducing staging/develop branch? If there is no
>>>> daily automation run verifying all the code merged from hotFixes/feature
>>>> branches (and possibly reverting wrong checkins), we can as well merge the
>>>> code directly to master.
>>>> 
>>> 
>>> Yes! - please.
>>> Doing this without CI as a gating factor buys us very little.
>>> 
>>> --David
>> 
>> David, can you clarify. Are you going to be against any change of git workflow until we get CI/BVT in place ?
>> 
> 
> No, please don't take it that way.
> I understand Leo's point about Cherry-picking being for fruit, and not
> code. But, I don't think that the workflow changes I've seen proposed
> affect quality. So shifting for quality's sake doesn't make a lot of
> sense in my mind. They could be a component of fixing the quality
> problem.
> 
> --David

Agreed, the changes don't affect quality but should support a CI infra that helps improves quality.

I do think the changes provide

-a stable master that represent released software
-a clean way to merge features and bug fixes
-a clean way to create a release that should reduce our time to release

Re: [VOTE] git workflow

[David Nalley <da...@gnsa.us>]

On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
>
>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>> <Al...@citrix.com> wrote:
>>> Edison, thank you for raising the concern about the BVT/CI. Somebody
>>> mentioned earlier that we should separate git workflow implementation from
>>> the CI effort, but I do think we have to do in in conjunction. Otherwise
>>> what is the point in introducing staging/develop branch? If there is no
>>> daily automation run verifying all the code merged from hotFixes/feature
>>> branches (and possibly reverting wrong checkins), we can as well merge the
>>> code directly to master.
>>>
>>
>> Yes! - please.
>> Doing this without CI as a gating factor buys us very little.
>>
>> --David
>
> David, can you clarify. Are you going to be against any change of git workflow until we get CI/BVT in place ?
>

No, please don't take it that way.
I understand Leo's point about Cherry-picking being for fruit, and not
code. But, I don't think that the workflow changes I've seen proposed
affect quality. So shifting for quality's sake doesn't make a lot of
sense in my mind. They could be a component of fixing the quality
problem.

--David

Re: [VOTE] git workflow

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

Here is where we stand:

1-We have a successful VOTE that got derailed after the voting period ended with a few -1
-> Since we should have a strong consensus on this that means that the VOTE is canned and folks who want a change are send back to the drawing board.

2-The main concerns I can see from the -1 are:
-> No quality control in place so any change in git workflow will not help.
-> Gitflow is for rolling releases and hence no suitable for cloudstack.

Any other concerns ?

3-I would love for us to agree on what is wrong with our current model ? Can folks start sharing their (bullet list) thoughts.
-> Master is not stable
-> Too many cherry picks.

Once we agree on what's wrong and what are the main concerns with the proposed git workflow, we can start drafting a plan to correct it ?

-Sebastien


On Aug 7, 2014, at 3:38 AM, Sebastien Goasguen <ru...@gmail.com> wrote:

> 
> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
> 
>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>> <Al...@citrix.com> wrote:
>>> Edison, thank you for raising the concern about the BVT/CI. Somebody
>>> mentioned earlier that we should separate git workflow implementation from
>>> the CI effort, but I do think we have to do in in conjunction. Otherwise
>>> what is the point in introducing staging/develop branch? If there is no
>>> daily automation run verifying all the code merged from hotFixes/feature
>>> branches (and possibly reverting wrong checkins), we can as well merge the
>>> code directly to master.
>>> 
>> 
>> Yes! - please.
>> Doing this without CI as a gating factor buys us very little.
>> 
>> --David
> 
> David, can you clarify. Are you going to be against any change of git workflow until we get CI/BVT in place ?
> 

Re: [VOTE] git workflow

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

On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote:

> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
> <Al...@citrix.com> wrote:
>> Edison, thank you for raising the concern about the BVT/CI. Somebody
>> mentioned earlier that we should separate git workflow implementation from
>> the CI effort, but I do think we have to do in in conjunction. Otherwise
>> what is the point in introducing staging/develop branch? If there is no
>> daily automation run verifying all the code merged from hotFixes/feature
>> branches (and possibly reverting wrong checkins), we can as well merge the
>> code directly to master.
>> 
> 
> Yes! - please.
> Doing this without CI as a gating factor buys us very little.
> 
> --David

David, can you clarify. Are you going to be against any change of git workflow until we get CI/BVT in place ?

Re: [VOTE] git workflow

[David Nalley <da...@gnsa.us>]

On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
<Al...@citrix.com> wrote:
> Edison, thank you for raising the concern about the BVT/CI. Somebody
> mentioned earlier that we should separate git workflow implementation from
> the CI effort, but I do think we have to do in in conjunction. Otherwise
> what is the point in introducing staging/develop branch? If there is no
> daily automation run verifying all the code merged from hotFixes/feature
> branches (and possibly reverting wrong checkins), we can as well merge the
> code directly to master.
>

Yes! - please.
Doing this without CI as a gating factor buys us very little.

--David

RE: [VOTE] git workflow

[Prachi Damle <Pr...@citrix.com>]

-----Original Message-----
From: Sebastien Goasguen [mailto:runseb@gmail.com] 
Sent: Wednesday, August 06, 2014 3:23 PM
To: dev@cloudstack.apache.org
Cc: Edison Su
Subject: Re: [VOTE] git workflow


On Aug 6, 2014, at 6:13 PM, Prachi Damle <Pr...@citrix.com> wrote:

> 
>> Edison, thank you for raising the concern about the BVT/CI. Somebody mentioned earlier that we should separate git workflow implementation from the CI effort, but I do think we have to do in in conjunction. Otherwise what is the point in introducing staging/develop branch? If there is no daily >automation run verifying all the code merged from hotFixes/feature branches (and possibly reverting wrong checkins), we can as well merge the code directly to master.
> 
>> -Alena.
> 
> 
> I agree to this. 
> 
> 1) If we are introducing the 'develop' branch, it intuitively seems that it should act as a staging branch where we have some quality control before things move to master.
> 2) Plus as discussed in the thread, the git workflow is not solving the CS maintenance release process. So we need to have some tweaks there to support the non-rolling release model of CS.
> 
> The reservation is not due to mere a 'naming' change -it's because apart from the naming change, we are still facing issues.

Can you list them specifically, one by one ?

That's what is listed above #1 and #2 - We are introducing 'develop' without any quality benefit and we will possibly break the maintenance release CS model.

> The proposal needs to address the above, if we are planning to introduce a change, why not solve our quality/test problems with it.
> 

Let's assume we have a CI/BVT infra available in apache and that every branch/commit can go through it. 
What would be your ideal git workflow to have:

-stable master (meaning that you checkout master and you have the latest shippable product) -always release on-time.
-always know where a fix should be applied (and if it has been applied everywhere)

(those are my top three, we may want to add others)



> Thanks,
> Prachi
> 
> On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
> 
>> 
>> 
>>> -----Original Message-----
>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>>> Sent: Wednesday, August 06, 2014 12:59 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [VOTE] git workflow
>>> 
>>> 
>>> 
>>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
>>> 
>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk < 
>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>> 
>>>>> Agree with you, Rohit. The changes to the git model we use, are 
>>>>> needed  indeed. But we should address only the problems that CS 
>>>>> faces, and the  main problem - quality control. The proposal 
>>>>> should be limited just to the  changes that are really needed for 
>>>>> the CS, and that will work with the  current CS model (minor 
>>>>> maintenance releases support is a part of it)
>>>>> 
>>>>> 
>>>> 
>>>> Theoretically you don't really have to change anything other than 
>>>> merging instead of cherry picking.
>>>> That is the main issue from a release perspective.
>>>> 
>>>> But I still think there are good reasons to do so;
>>>> 
>>>> 1) using a well known way of handling code/releases instantly tells 
>>>> new contributors / committers how we work. add to the fact that 
>>>> there exists tools to help doing this correctly is a bonus.
>>>> 2) having a known stable (atleast in theory) release as master is 
>>>> good practice. although not many users will be running from git, i 
>>>> still consider it to be good practice.
>>>> 3) there is a huge belief in this thread/discussion that as long as 
>>>> something passes CI / BVT it is considered stable. The fact is that 
>>>> it is not. Take the recent 4.4 release as a good example, where a 
>>>> new install was not working at all at the point of release. Now, 
>>>> this is more a CI / test coverage issue than git workflow issue, 
>>>> but i find it weird to use as an argument for not improving the workflow.
>>>> 
>>>> --
>>>> Erik
>>> 
>>> I¹m not arguing against keeping master release stable; I advocate 
>>> for it.
>> 
>> +1, we need to take action to make sure master is stable. Frankly
>> speaking,
>> I don't want to fix the regression on the master, I assume nobody 
>> want to do that.
>> Here is the list of regression issues(not introduced by myself) I 
>> fixed on master after 4.4:
>> 
>> CLOUDSTACK-7123
>> CLOUDSTACK-7110
>> CLOUDSTACK-7166
>> CLOUDSTACK-7164
>> Most of this issues will be caught even by a simulator BVT. I want to 
>> make it clear, that, If we don't take action to reduce/eliminate the 
>> regression as much as possible in the future, I will not fix any of 
>> this regression issues.
>> I remember there is discussion about setting up a staging branch, run 
>> BVT against it for each commit, what's the conclusion if any? Why so 
>> difficult to make it happen? Is there anything I can help to make it 
>> happen?
>> 
>>> But we can¹t adopt git workflow way of keeping master branch to be a 
>>> reflection of the latest release branch. It will not work with our 
>>> way of  handling maintenance releases for multiple versions of CS - 
>>> see another  thread.
>> 
>> 
>> +1, I'll -1 on any of proposal, if it doesn't solve problem most of 
>> +us
>> are concerning about.
>> 
>>> 
>>> Instead, master branch should reflect the latest code that passed 
>>> the CI test  (the code merged from *develop after CI passes). The 
>>> release branches  should be cut from stable master branch - it will 
>>> ensure that we won¹t face  last minute blockers as for 4.4, because 
>>> master IS a stable branch.
>>> And yes, we should do merges instead of cherry picking.
>>> 
>>> 
>>> 
>>>> 
>> 
> 

Re: [VOTE] git workflow

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

On Aug 6, 2014, at 6:13 PM, Prachi Damle <Pr...@citrix.com> wrote:

> 
>> Edison, thank you for raising the concern about the BVT/CI. Somebody mentioned earlier that we should separate git workflow implementation from the CI effort, but I do think we have to do in in conjunction. Otherwise what is the point in introducing staging/develop branch? If there is no daily >automation run verifying all the code merged from hotFixes/feature branches (and possibly reverting wrong checkins), we can as well merge the code directly to master.
> 
>> -Alena.
> 
> 
> I agree to this. 
> 
> 1) If we are introducing the 'develop' branch, it intuitively seems that it should act as a staging branch where we have some quality control before things move to master.
> 2) Plus as discussed in the thread, the git workflow is not solving the CS maintenance release process. So we need to have some tweaks there to support the non-rolling release model of CS.
> 
> The reservation is not due to mere a 'naming' change -it's because apart from the naming change, we are still facing issues.

Can you list them specifically, one by one ?


> The proposal needs to address the above, if we are planning to introduce a change, why not solve our quality/test problems with it.
> 

Let's assume we have a CI/BVT infra available in apache and that every branch/commit can go through it. 
What would be your ideal git workflow to have:

-stable master (meaning that you checkout master and you have the latest shippable product)
-always release on-time.
-always know where a fix should be applied (and if it has been applied everywhere)

(those are my top three, we may want to add others)



> Thanks,
> Prachi
> 
> On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:
> 
>> 
>> 
>>> -----Original Message-----
>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>>> Sent: Wednesday, August 06, 2014 12:59 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [VOTE] git workflow
>>> 
>>> 
>>> 
>>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
>>> 
>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk < 
>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>> 
>>>>> Agree with you, Rohit. The changes to the git model we use, are 
>>>>> needed  indeed. But we should address only the problems that CS 
>>>>> faces, and the  main problem - quality control. The proposal should 
>>>>> be limited just to the  changes that are really needed for the CS, 
>>>>> and that will work with the  current CS model (minor maintenance 
>>>>> releases support is a part of it)
>>>>> 
>>>>> 
>>>> 
>>>> Theoretically you don't really have to change anything other than 
>>>> merging instead of cherry picking.
>>>> That is the main issue from a release perspective.
>>>> 
>>>> But I still think there are good reasons to do so;
>>>> 
>>>> 1) using a well known way of handling code/releases instantly tells 
>>>> new contributors / committers how we work. add to the fact that 
>>>> there exists tools to help doing this correctly is a bonus.
>>>> 2) having a known stable (atleast in theory) release as master is 
>>>> good practice. although not many users will be running from git, i 
>>>> still consider it to be good practice.
>>>> 3) there is a huge belief in this thread/discussion that as long as 
>>>> something passes CI / BVT it is considered stable. The fact is that 
>>>> it is not. Take the recent 4.4 release as a good example, where a 
>>>> new install was not working at all at the point of release. Now, 
>>>> this is more a CI / test coverage issue than git workflow issue, but 
>>>> i find it weird to use as an argument for not improving the workflow.
>>>> 
>>>> --
>>>> Erik
>>> 
>>> I¹m not arguing against keeping master release stable; I advocate for 
>>> it.
>> 
>> +1, we need to take action to make sure master is stable. Frankly
>> speaking,
>> I don't want to fix the regression on the master, I assume nobody want 
>> to do that.
>> Here is the list of regression issues(not introduced by myself) I fixed 
>> on master after 4.4:
>> 
>> CLOUDSTACK-7123
>> CLOUDSTACK-7110
>> CLOUDSTACK-7166
>> CLOUDSTACK-7164
>> Most of this issues will be caught even by a simulator BVT. I want to 
>> make it clear, that, If we don't take action to reduce/eliminate the 
>> regression as much as possible in the future, I will not fix any of 
>> this regression issues.
>> I remember there is discussion about setting up a staging branch, run 
>> BVT against it for each commit, what's the conclusion if any? Why so 
>> difficult to make it happen? Is there anything I can help to make it 
>> happen?
>> 
>>> But we can¹t adopt git workflow way of keeping master branch to be a  
>>> reflection of the latest release branch. It will not work with our way 
>>> of  handling maintenance releases for multiple versions of CS - see 
>>> another  thread.
>> 
>> 
>> +1, I'll -1 on any of proposal, if it doesn't solve problem most of us
>> are concerning about.
>> 
>>> 
>>> Instead, master branch should reflect the latest code that passed the 
>>> CI test  (the code merged from *develop after CI passes). The release 
>>> branches  should be cut from stable master branch - it will ensure 
>>> that we won¹t face  last minute blockers as for 4.4, because master IS 
>>> a stable branch.
>>> And yes, we should do merges instead of cherry picking.
>>> 
>>> 
>>> 
>>>> 
>> 
> 

RE: [VOTE] git workflow

[Prachi Damle <Pr...@citrix.com>]

>Edison, thank you for raising the concern about the BVT/CI. Somebody mentioned earlier that we should separate git workflow implementation from the CI effort, but I do think we have to do in in conjunction. Otherwise what is the point in introducing staging/develop branch? If there is no daily >automation run verifying all the code merged from hotFixes/feature branches (and possibly reverting wrong checkins), we can as well merge the code directly to master.

>-Alena.


I agree to this. 

1) If we are introducing the 'develop' branch, it intuitively seems that it should act as a staging branch where we have some quality control before things move to master.
2) Plus as discussed in the thread, the git workflow is not solving the CS maintenance release process. So we need to have some tweaks there to support the non-rolling release model of CS.

The reservation is not due to mere a 'naming' change -it's because apart from the naming change, we are still facing issues. The proposal needs to address the above, if we are planning to introduce a change, why not solve our quality/test problems with it.

Thanks,
Prachi

On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:

>
>
>> -----Original Message-----
>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>> Sent: Wednesday, August 06, 2014 12:59 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] git workflow
>> 
>> 
>> 
>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
>> 
>> >On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk < 
>> >Alena.Prokharchyk@citrix.com> wrote:
>> >
>> >> Agree with you, Rohit. The changes to the git model we use, are 
>> >>needed  indeed. But we should address only the problems that CS 
>> >>faces, and the  main problem - quality control. The proposal should 
>> >>be limited just to the  changes that are really needed for the CS, 
>> >>and that will work with the  current CS model (minor maintenance 
>> >>releases support is a part of it)
>> >>
>> >>
>> >
>> >Theoretically you don't really have to change anything other than 
>> >merging instead of cherry picking.
>> >That is the main issue from a release perspective.
>> >
>> >But I still think there are good reasons to do so;
>> >
>> >1) using a well known way of handling code/releases instantly tells 
>> >new contributors / committers how we work. add to the fact that 
>> >there exists tools to help doing this correctly is a bonus.
>> >2) having a known stable (atleast in theory) release as master is 
>> >good practice. although not many users will be running from git, i 
>> >still consider it to be good practice.
>> >3) there is a huge belief in this thread/discussion that as long as 
>> >something passes CI / BVT it is considered stable. The fact is that 
>> >it is not. Take the recent 4.4 release as a good example, where a 
>> >new install was not working at all at the point of release. Now, 
>> >this is more a CI / test coverage issue than git workflow issue, but 
>> >i find it weird to use as an argument for not improving the workflow.
>> >
>> >--
>> >Erik
>> 
>> I¹m not arguing against keeping master release stable; I advocate for 
>>it.
>
>+1, we need to take action to make sure master is stable. Frankly
>speaking,
>I don't want to fix the regression on the master, I assume nobody want 
>to do that.
>Here is the list of regression issues(not introduced by myself) I fixed 
>on master after 4.4:
>
>CLOUDSTACK-7123
>CLOUDSTACK-7110
>CLOUDSTACK-7166
>CLOUDSTACK-7164
>Most of this issues will be caught even by a simulator BVT. I want to 
>make it clear, that, If we don't take action to reduce/eliminate the 
>regression as much as possible in the future, I will not fix any of 
>this regression issues.
>I remember there is discussion about setting up a staging branch, run 
>BVT against it for each commit, what's the conclusion if any? Why so 
>difficult to make it happen? Is there anything I can help to make it 
>happen?
>
>> But we can¹t adopt git workflow way of keeping master branch to be a  
>>reflection of the latest release branch. It will not work with our way 
>>of  handling maintenance releases for multiple versions of CS - see 
>>another  thread.
>
>
>+1, I'll -1 on any of proposal, if it doesn't solve problem most of us
>are concerning about.
>
>> 
>> Instead, master branch should reflect the latest code that passed the 
>>CI test  (the code merged from *develop after CI passes). The release 
>>branches  should be cut from stable master branch - it will ensure 
>>that we won¹t face  last minute blockers as for 4.4, because master IS 
>>a stable branch.
>> And yes, we should do merges instead of cherry picking.
>> 
>> 
>> 
>> >
>

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Edison, thank you for raising the concern about the BVT/CI. Somebody
mentioned earlier that we should separate git workflow implementation from
the CI effort, but I do think we have to do in in conjunction. Otherwise
what is the point in introducing staging/develop branch? If there is no
daily automation run verifying all the code merged from hotFixes/feature
branches (and possibly reverting wrong checkins), we can as well merge the
code directly to master.

-Alena.

On 8/6/14, 2:30 PM, "Edison Su" <Ed...@citrix.com> wrote:

>
>
>> -----Original Message-----
>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>> Sent: Wednesday, August 06, 2014 12:59 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] git workflow
>> 
>> 
>> 
>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
>> 
>> >On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>> >Alena.Prokharchyk@citrix.com> wrote:
>> >
>> >> Agree with you, Rohit. The changes to the git model we use, are
>> >>needed  indeed. But we should address only the problems that CS faces,
>> >>and the  main problem - quality control. The proposal should be
>> >>limited just to the  changes that are really needed for the CS, and
>> >>that will work with the  current CS model (minor maintenance releases
>> >>support is a part of it)
>> >>
>> >>
>> >
>> >Theoretically you don't really have to change anything other than
>> >merging instead of cherry picking.
>> >That is the main issue from a release perspective.
>> >
>> >But I still think there are good reasons to do so;
>> >
>> >1) using a well known way of handling code/releases instantly tells new
>> >contributors / committers how we work. add to the fact that there
>> >exists tools to help doing this correctly is a bonus.
>> >2) having a known stable (atleast in theory) release as master is good
>> >practice. although not many users will be running from git, i still
>> >consider it to be good practice.
>> >3) there is a huge belief in this thread/discussion that as long as
>> >something passes CI / BVT it is considered stable. The fact is that it
>> >is not. Take the recent 4.4 release as a good example, where a new
>> >install was not working at all at the point of release. Now, this is
>> >more a CI / test coverage issue than git workflow issue, but i find it
>> >weird to use as an argument for not improving the workflow.
>> >
>> >--
>> >Erik
>> 
>> I¹m not arguing against keeping master release stable; I advocate for
>>it.
>
>+1, we need to take action to make sure master is stable. Frankly
>speaking, 
>I don't want to fix the regression on the master, I assume nobody want to
>do that.
>Here is the list of regression issues(not introduced by myself) I fixed
>on master after 4.4:
>
>CLOUDSTACK-7123
>CLOUDSTACK-7110
>CLOUDSTACK-7166
>CLOUDSTACK-7164
>Most of this issues will be caught even by a simulator BVT. I want to
>make it clear, that,
>If we don't take action to reduce/eliminate the regression as much as
>possible in the future, I will not fix any of this regression issues.
>I remember there is discussion about setting up a staging branch, run BVT
>against it for each commit, what's the conclusion if any? Why so
>difficult to make it happen? Is there anything I can help to make it
>happen?
>
>> But we can¹t adopt git workflow way of keeping master branch to be a
>> reflection of the latest release branch. It will not work with our way
>>of
>> handling maintenance releases for multiple versions of CS - see another
>> thread.
>
>
>+1, I'll -1 on any of proposal, if it doesn't solve problem most of us
>are concerning about.
>
>> 
>> Instead, master branch should reflect the latest code that passed the
>>CI test
>> (the code merged from *develop after CI passes). The release branches
>> should be cut from stable master branch - it will ensure that we won¹t
>>face
>> last minute blockers as for 4.4, because master IS a stable branch.
>> And yes, we should do merges instead of cherry picking.
>> 
>> 
>> 
>> >
>

RE: [VOTE] git workflow

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

> -----Original Message-----
> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> Sent: Wednesday, August 06, 2014 12:59 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] git workflow
> 
> 
> 
> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
> 
> >On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
> >Alena.Prokharchyk@citrix.com> wrote:
> >
> >> Agree with you, Rohit. The changes to the git model we use, are
> >>needed  indeed. But we should address only the problems that CS faces,
> >>and the  main problem - quality control. The proposal should be
> >>limited just to the  changes that are really needed for the CS, and
> >>that will work with the  current CS model (minor maintenance releases
> >>support is a part of it)
> >>
> >>
> >
> >Theoretically you don't really have to change anything other than
> >merging instead of cherry picking.
> >That is the main issue from a release perspective.
> >
> >But I still think there are good reasons to do so;
> >
> >1) using a well known way of handling code/releases instantly tells new
> >contributors / committers how we work. add to the fact that there
> >exists tools to help doing this correctly is a bonus.
> >2) having a known stable (atleast in theory) release as master is good
> >practice. although not many users will be running from git, i still
> >consider it to be good practice.
> >3) there is a huge belief in this thread/discussion that as long as
> >something passes CI / BVT it is considered stable. The fact is that it
> >is not. Take the recent 4.4 release as a good example, where a new
> >install was not working at all at the point of release. Now, this is
> >more a CI / test coverage issue than git workflow issue, but i find it
> >weird to use as an argument for not improving the workflow.
> >
> >--
> >Erik
> 
> I¹m not arguing against keeping master release stable; I advocate for it.

+1, we need to take action to make sure master is stable. Frankly speaking, 
I don't want to fix the regression on the master, I assume nobody want to do that.
Here is the list of regression issues(not introduced by myself) I fixed on master after 4.4:

CLOUDSTACK-7123
CLOUDSTACK-7110
CLOUDSTACK-7166
CLOUDSTACK-7164
Most of this issues will be caught even by a simulator BVT. I want to make it clear, that,
If we don't take action to reduce/eliminate the regression as much as possible in the future, I will not fix any of this regression issues.
I remember there is discussion about setting up a staging branch, run BVT against it for each commit, what's the conclusion if any? Why so difficult to make it happen? Is there anything I can help to make it happen?

> But we can¹t adopt git workflow way of keeping master branch to be a
> reflection of the latest release branch. It will not work with our way of
> handling maintenance releases for multiple versions of CS - see another
> thread.


+1, I'll -1 on any of proposal, if it doesn't solve problem most of us are concerning about.

> 
> Instead, master branch should reflect the latest code that passed the CI test
> (the code merged from *develop after CI passes). The release branches
> should be cut from stable master branch - it will ensure that we won¹t face
> last minute blockers as for 4.4, because master IS a stable branch.
> And yes, we should do merges instead of cherry picking.
> 
> 
> 
> >

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Daan, thank you for the summary. See my answers below.



On 8/6/14, 1:59 PM, "Daan Hoogland" <da...@gmail.com> wrote:

>Alena,
>
>I think this is a matter of semantics. If you call the latest version
>that got through the CI a pre-release and add them as releases in the
>git-flow way of working on master you've got what you envision.

Yes.

>
>In spite of my mail this morning I am not a warrior (though I like the
>compliment, Rohit) of gitflow but I feel that it fits whatever we need
>so far. 

My main point of objection was the way they maintain the master branch -
to reflect the latest release, which doesn’t suit the CS maintenance
releases model. Plus we can’t remove the release branches like the
original model does.



>I have read no contradiction to that so far. The only real
>change to our present way of working , given that we will use support
>branches, is that we don't build releases on the basis of cherry-picks
>anymore, which is not a very big change. Other then that, naming is
>all that is left.

Yes, merges instead of cherry-picks and introducing a staging (*develop,
or *pre-release) branch - that was all missing in the CS before, and we
have to implement it.

>
>Maybe I lost view on the obstacles and objections and am being short
>sighted here, please advice,
>Daan
>
>On Wed, Aug 6, 2014 at 9:59 PM, Alena Prokharchyk
><Al...@citrix.com> wrote:
>>
>>
>> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
>>
>>>On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>>>Alena.Prokharchyk@citrix.com> wrote:
>>>
>>>> Agree with you, Rohit. The changes to the git model we use, are needed
>>>> indeed. But we should address only the problems that CS faces, and the
>>>> main problem - quality control. The proposal should be limited just to
>>>>the
>>>> changes that are really needed for the CS, and that will work with the
>>>> current CS model (minor maintenance releases support is a part of it)
>>>>
>>>>
>>>
>>>Theoretically you don't really have to change anything other than
>>>merging
>>>instead of cherry picking.
>>>That is the main issue from a release perspective.
>>>
>>>But I still think there are good reasons to do so;
>>>
>>>1) using a well known way of handling code/releases instantly tells new
>>>contributors / committers how we work. add to the fact that there exists
>>>tools to help doing this correctly is a bonus.
>>>2) having a known stable (atleast in theory) release as master is good
>>>practice. although not many users will be running from git, i still
>>>consider it to be good practice.
>>>3) there is a huge belief in this thread/discussion that as long as
>>>something passes CI / BVT it is considered stable. The fact is that it
>>>is
>>>not. Take the recent 4.4 release as a good example, where a new install
>>>was
>>>not working at all at the point of release. Now, this is more a CI /
>>>test
>>>coverage issue than git workflow issue, but i find it weird to use as an
>>>argument for not improving the workflow.
>>>
>>>--
>>>Erik
>>
>> I¹m not arguing against keeping master release stable; I advocate for
>>it.
>> But we can¹t adopt git workflow way of keeping master branch to be a
>> reflection of the latest release branch. It will not work with our way
>>of
>> handling maintenance releases for multiple versions of CS - see another
>> thread.
>>
>> Instead, master branch should reflect the latest code that passed the CI
>> test (the code merged from *develop after CI passes). The release
>>branches
>> should be cut from stable master branch - it will ensure that we won¹t
>> face last minute blockers as for 4.4, because master IS a stable branch.
>> And yes, we should do merges instead of cherry picking.
>>
>>
>>
>>>
>>
>
>
>
>-- 
>Daan

Re: [VOTE] git workflow

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

Alena,

I think this is a matter of semantics. If you call the latest version
that got through the CI a pre-release and add them as releases in the
git-flow way of working on master you've got what you envision.

In spite of my mail this morning I am not a warrior (though I like the
compliment, Rohit) of gitflow but I feel that it fits whatever we need
so far. I have read no contradiction to that so far. The only real
change to our present way of working , given that we will use support
branches, is that we don't build releases on the basis of cherry-picks
anymore, which is not a very big change. Other then that, naming is
all that is left.

Maybe I lost view on the obstacles and objections and am being short
sighted here, please advice,
Daan

On Wed, Aug 6, 2014 at 9:59 PM, Alena Prokharchyk
<Al...@citrix.com> wrote:
>
>
> On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:
>
>>On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>>Alena.Prokharchyk@citrix.com> wrote:
>>
>>> Agree with you, Rohit. The changes to the git model we use, are needed
>>> indeed. But we should address only the problems that CS faces, and the
>>> main problem - quality control. The proposal should be limited just to
>>>the
>>> changes that are really needed for the CS, and that will work with the
>>> current CS model (minor maintenance releases support is a part of it)
>>>
>>>
>>
>>Theoretically you don't really have to change anything other than merging
>>instead of cherry picking.
>>That is the main issue from a release perspective.
>>
>>But I still think there are good reasons to do so;
>>
>>1) using a well known way of handling code/releases instantly tells new
>>contributors / committers how we work. add to the fact that there exists
>>tools to help doing this correctly is a bonus.
>>2) having a known stable (atleast in theory) release as master is good
>>practice. although not many users will be running from git, i still
>>consider it to be good practice.
>>3) there is a huge belief in this thread/discussion that as long as
>>something passes CI / BVT it is considered stable. The fact is that it is
>>not. Take the recent 4.4 release as a good example, where a new install
>>was
>>not working at all at the point of release. Now, this is more a CI / test
>>coverage issue than git workflow issue, but i find it weird to use as an
>>argument for not improving the workflow.
>>
>>--
>>Erik
>
> I¹m not arguing against keeping master release stable; I advocate for it.
> But we can¹t adopt git workflow way of keeping master branch to be a
> reflection of the latest release branch. It will not work with our way of
> handling maintenance releases for multiple versions of CS - see another
> thread.
>
> Instead, master branch should reflect the latest code that passed the CI
> test (the code merged from *develop after CI passes). The release branches
> should be cut from stable master branch - it will ensure that we won¹t
> face last minute blockers as for 4.4, because master IS a stable branch.
> And yes, we should do merges instead of cherry picking.
>
>
>
>>
>



-- 
Daan

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

On 8/6/14, 12:52 PM, "Erik Weber" <te...@gmail.com> wrote:

>On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>Alena.Prokharchyk@citrix.com> wrote:
>
>> Agree with you, Rohit. The changes to the git model we use, are needed
>> indeed. But we should address only the problems that CS faces, and the
>> main problem - quality control. The proposal should be limited just to
>>the
>> changes that are really needed for the CS, and that will work with the
>> current CS model (minor maintenance releases support is a part of it)
>>
>>
>
>Theoretically you don't really have to change anything other than merging
>instead of cherry picking.
>That is the main issue from a release perspective.
>
>But I still think there are good reasons to do so;
>
>1) using a well known way of handling code/releases instantly tells new
>contributors / committers how we work. add to the fact that there exists
>tools to help doing this correctly is a bonus.
>2) having a known stable (atleast in theory) release as master is good
>practice. although not many users will be running from git, i still
>consider it to be good practice.
>3) there is a huge belief in this thread/discussion that as long as
>something passes CI / BVT it is considered stable. The fact is that it is
>not. Take the recent 4.4 release as a good example, where a new install
>was
>not working at all at the point of release. Now, this is more a CI / test
>coverage issue than git workflow issue, but i find it weird to use as an
>argument for not improving the workflow.
>
>-- 
>Erik

I¹m not arguing against keeping master release stable; I advocate for it.
But we can¹t adopt git workflow way of keeping master branch to be a
reflection of the latest release branch. It will not work with our way of
handling maintenance releases for multiple versions of CS - see another
thread.

Instead, master branch should reflect the latest code that passed the CI
test (the code merged from *develop after CI passes). The release branches
should be cut from stable master branch - it will ensure that we won¹t
face last minute blockers as for 4.4, because master IS a stable branch.
And yes, we should do merges instead of cherry picking.



>

Re: [VOTE] git workflow

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

On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> Agree with you, Rohit. The changes to the git model we use, are needed
> indeed. But we should address only the problems that CS faces, and the
> main problem - quality control. The proposal should be limited just to the
> changes that are really needed for the CS, and that will work with the
> current CS model (minor maintenance releases support is a part of it)
>
>

Theoretically you don't really have to change anything other than merging
instead of cherry picking.
That is the main issue from a release perspective.

But I still think there are good reasons to do so;

1) using a well known way of handling code/releases instantly tells new
contributors / committers how we work. add to the fact that there exists
tools to help doing this correctly is a bonus.
2) having a known stable (atleast in theory) release as master is good
practice. although not many users will be running from git, i still
consider it to be good practice.
3) there is a huge belief in this thread/discussion that as long as
something passes CI / BVT it is considered stable. The fact is that it is
not. Take the recent 4.4 release as a good example, where a new install was
not working at all at the point of release. Now, this is more a CI / test
coverage issue than git workflow issue, but i find it weird to use as an
argument for not improving the workflow.

-- 
Erik

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Agree with you, Rohit. The changes to the git model we use, are needed
indeed. But we should address only the problems that CS faces, and the
main problem - quality control. The proposal should be limited just to the
changes that are really needed for the CS, and that will work with the
current CS model (minor maintenance releases support is a part of it)

Briefly, I think we should do this:

* introduce staging branch. We can call it “develop”. Develop branch gets
merged daily into master only after CI runs/passes on it.
* Master branch reflects the latest changes from *develop, that passed the
quality control.
* release branches cut from the stable master branch only.
* people working on hot fixes/features/critical bugs (where collaboration
is needed), have to cut their own branch from *develop tree. And merge the
fix to *develop only after running automation on their branches (BVT or CI
- to be discussed). Extra daily CI run on *develop branch will ensure that
fixes committed by various people to *develop branch along the day, don’t
break anything.


Thank you,
Alena. 

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

>Hi,
>
>If it was not clear, let me re-state — just because I’m participating in
>this thread does not mean I fully support git-flow, or I am here to
>defend it.
>
>The proposal thread warriors Rajani, Daan, Leo and others can comment and
>advise?
>
>I like couple of good ideas in it, and I think it’s better than what we
>do, especially the baseline protocol. I want to take good stuff from it
>and adapt them to our workflow. As I see now, this won't change our
>process/workflow a lot or that it can stop bad commits or practices from
>happening in our repositories.
>
>I’ve emailed git-flow’s author about raised issues, will keep everyone
>posted.
>
>Cheers.
>
>On 06-Aug-2014, at 8:29 pm, Alena Prokharchyk
><Al...@citrix.com> wrote:
>>
>> On 8/6/14, 11:22 AM, "David Nalley" <da...@gnsa.us> wrote:
>>
>>> On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav <ro...@shapeblue.com>
>>> wrote:
>>>> Hi,
>>>>
>>>> On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk
>>>> <Al...@citrix.com> wrote:
>>>>
>>>>> Rohit, thank you for the explanation. So we cut the maintenance
>>>>>release
>>>>> from the master branch, not *develop as opposed to the major release
>>>>> branch.
>>>>>
>>>>> One more open question. Its clear that we cut the maintenance release
>>>>> from
>>>>> the master branch, but what would be the right way to merge it back
>>>>>if
>>>>> this is a maintenance release for say 4.2, and 4.4 is the top of the
>>>>> master branch? Where would the 4.2.1 tag appear? It can¹t be on a top
>>>>> of
>>>>> 4.4
>>>>
>>>> You checkout a support branch from 4.2 tag (or for that matter you may
>>>> keep the 4.2 release branch, it¹s same) for LTS/support.
>>>> You tag 4.2.1 on the support branch. (it¹s the same way you would do
>>>> like we do it now). I think git-flow is suitable for rolling releases
>>>> and may not 100% work with our deployment/release process. One thing
>>>> I¹ve suggested is shortening of our release cycles which can help.
>>>>
>>>
>>> So I suspect that checking out a tag would work. I don't know that
>>> once we create a tag, that we would be able to merge that back into
>>> master. Especially true for maintenance releases. How and where would
>>> we merge 4.5.1 back into master? Moreover, I don't see us getting out
>>> of checking out the tag, and creating a branch to work in. That means
>>> we'd delete a branch, check out a tag, create a branch, create a new
>>> tag, delete a branch - and repeat.
>>>
>>> That said, we don't currently have rolling releases - and now you are
>>> suggesting it may not 100% work. *sigh*
>>
>> Dave, you are right, we can¹t. There is no way to merge back minor
>> releases back to master branch, and preserve the history. The model
>>works
>> only for rolling releases. So making master reflect release branch won¹t
>> make sense in CS case.
>>
>>>
>>>> The flow of commits/fixes/changes would follow the baseline protocol ‹
>>>> from firm branch to soft branches chronologically, so if there is a
>>>>bug
>>>> on 4.2 release you fix it on 4.2 support branch and
>>>> cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch
>>>>and
>>>> then to 4.4 support branch Š to 4.5 release branch to develop branch.
>>>>
>>>> I think git-flow assumes the releases will be chronological so you
>>>> don¹t release 4.3.1 after 4.4 etc and you always progress? I¹m not
>>>>sure.
>>>> We can think of better ways of doing things, we can also learn from
>>>>how
>>>> other projects do it.
>>>>
>>>> Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be
>>>> painful, that always felt to me like maintaining a whole different
>>>> product. If we can do something about that, we¹re going to make a lot
>>>>of
>>>> people happy IMO.
>>>>
>>>>>
>>>
>>> So we've set the expectation that we'll follow SemVer - and adhering
>>> to that is a good thing. Rolling releases are interesting, but we are
>>> a long way from being able to do anything remotely close IMO.
>
>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] git workflow

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

Animesh, cherry-picking from a single branch will cause conflicts in
the long run (of two to three months) so it is a major problem with
the way we release now. Also it will add the code and I was not
convinced that merging was better until Leo showed me a history graph
as example. With merging a lot more history is preserved and it is
easier to see how the present state of the code came to be. I don't
think it is an end goal but it is very convenient for an RM.

On Thu, Aug 7, 2014 at 8:40 AM, Animesh Chaturvedi
<an...@citrix.com> wrote:
>
>>
>> (Like most of the internet...) I strongly believe using cherry picks as the basic
>> tool for (release) branch management is one of the worst choices you can
>> make.
>>
>> But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]
>>
> [Animesh] Leo I don't mind moving to merging branches rather than cherry-picking for technical reasons, but I am not sure cherry-picking is to blame entirely. Using it all the time caused the pain. When Chip and I were running releases we started cherry-picks when we got closer to RC. I did not see cherry-pick as a big pain for 4.2 and 4.3 where I was the RM.  RM cannot scale if they are spending most of their time in cherry-picking or merging branches into release branch.  It needs to be done when they  are reasonably confident that the churn will be limited otherwise RM will get drowned in all these requests (be it cherry-pick or merge branch).  And also I have used cherry-pick with -x flag which appends "cherry-picked from ...'  to the original commit message in order to indicate which commit this change was cherry-picked from.
>
>
>
>



-- 
Daan

RE: [VOTE] git workflow

[Raja Pullela <ra...@citrix.com>]

Daan,  

+1 for having stable master branch wherein we bring only tested "development" branches into master.  
-1 against having a shadow branches to stable/master and pushing changes into stable based on just CI test runs.  I agree it is better than what we have currently.  But does not solve/address the stability issue completely.

Thanks,
Raja
-----Original Message-----
From: Daan Hoogland [mailto:daan.hoogland@gmail.com] 
Sent: Thursday, August 07, 2014 2:46 PM
To: dev
Subject: Re: [VOTE] git workflow

Raja,

On Thu, Aug 7, 2014 at 11:03 AM, Raja Pullela <ra...@citrix.com> wrote:
> If we are using "Development" branch as a shadow branch for "Stable" - is not worth going that route because the existing automation may not find all the issues.  As a result, "Stable" is not completely protected from breakage or failure.
>
> "Stable" should have the last stable released code.
> "Development" should be the release in progress and not a shadow branch for "Stable"
> There should be merges from "Stable" to "Development"  if there are 
> any HOTFIX/Maintenance releases that get released from "Stable" before the "Development"/Release in progress goes out After QA completes testing, "Development" should get into "Stable"
> Following the "development" merge into "Stable", cut a "Release" 
> Branch Any final bug fixes that are absolutely necessary before the 
> Release, will get fixed on the "Release" Branch Release software from 
> the "Release" Branch After Release, "Release" Branch goes into "Stable"
> From then onwards, "Stable" will have the new Release code

I could read your response both as a +1 and as a counter proposal.
What is your point? We do not protect our users against breakage completely now and we will not in the future. Is your point that we should only change to something if that completely protects us from all failure?

> A similar approach was discussed in the wikis/blogs shared by Rajani and Sheng.
Yes, and...

can we,
> work on a 'development' branch.
> merge on a nightly basis to a stable branch given the status of 'development' is 'passing'
> branch release branches as 'x.y' from 'stable'
> merge them back to 'stable' when stable and tag them as 'x.y.z'.
> branch from 'x.y.z' when support branches need to be made as 'x.y' 
> again do not merge those back in principle but keep those around for 
> users to play with and because 'stable' and 'develop' continue 
> </proposal>


--
Daan

Re: [VOTE] git workflow

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

Raja,

On Thu, Aug 7, 2014 at 11:03 AM, Raja Pullela <ra...@citrix.com> wrote:
> If we are using "Development" branch as a shadow branch for "Stable" - is not worth going that route because the existing automation may not find all the issues.  As a result, "Stable" is not completely protected from breakage or failure.
>
> "Stable" should have the last stable released code.
> "Development" should be the release in progress and not a shadow branch for "Stable"
> There should be merges from "Stable" to "Development"  if there are any HOTFIX/Maintenance releases that get released from "Stable" before the "Development"/Release in progress goes out
> After QA completes testing, "Development" should get into "Stable"
> Following the "development" merge into "Stable", cut a "Release" Branch
> Any final bug fixes that are absolutely necessary before the Release, will get fixed on the "Release" Branch
> Release software from the "Release" Branch
> After Release, "Release" Branch goes into "Stable"
> From then onwards, "Stable" will have the new Release code

I could read your response both as a +1 and as a counter proposal.
What is your point? We do not protect our users against breakage
completely now and we will not in the future. Is your point that we
should only change to something if that completely protects us from
all failure?

> A similar approach was discussed in the wikis/blogs shared by Rajani and Sheng.
Yes, and...

can we,
> work on a 'development' branch.
> merge on a nightly basis to a stable branch given the status of 'development' is 'passing'
> branch release branches as 'x.y' from 'stable'
> merge them back to 'stable' when stable and tag them as 'x.y.z'.
> branch from 'x.y.z' when support branches need to be made as 'x.y' again do not merge those back in principle but keep those around for users to play with and because 'stable' and 'develop' continue </proposal>


-- 
Daan

RE: [VOTE] git workflow

[Raja Pullela <ra...@citrix.com>]

If we are using "Development" branch as a shadow branch for "Stable" - is not worth going that route because the existing automation may not find all the issues.  As a result, "Stable" is not completely protected from breakage or failure.

"Stable" should have the last stable released code.
"Development" should be the release in progress and not a shadow branch for "Stable"
There should be merges from "Stable" to "Development"  if there are any HOTFIX/Maintenance releases that get released from "Stable" before the "Development"/Release in progress goes out
After QA completes testing, "Development" should get into "Stable"
Following the "development" merge into "Stable", cut a "Release" Branch
Any final bug fixes that are absolutely necessary before the Release, will get fixed on the "Release" Branch
Release software from the "Release" Branch
After Release, "Release" Branch goes into "Stable"
From then onwards, "Stable" will have the new Release code 

A similar approach was discussed in the wikis/blogs shared by Rajani and Sheng.

Thanks,
Raja
-----Original Message-----
From: Daan Hoogland [mailto:daan.hoogland@gmail.com] 
Sent: Thursday, August 07, 2014 2:03 PM
To: dev
Subject: Re: [VOTE] git workflow

I am not for grand proposals so I don't agree that we should first make an inventory of all problems. The idea that we are going to do CI on a staging branch I take for a fact for the moment. Given that I would like to propose that we:

<proposal version='future'>
work on a 'development' branch.
merge on a nightly basis to a stable branch given the status of 'development' is 'passing'
branch release branches as 'x.y' from 'stable'
merge them back to 'stable' when stable and tag them as 'x.y.z'.
branch from 'x.y.z' when support branches need to be made as 'x.y' again do not merge those back in principle but keep those around for users to play with and because 'stable' and 'develop' continue </proposal>

Whether we use gitflow is irrelevant in this. What other changes we do as well. i.e. git pull instead of review board, using ci on 'development' or other branches.

Is this good enough for a vote?

regards,
Daan


On Thu, Aug 7, 2014 at 10:15 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hey,
>
> On 07-Aug-2014, at 9:22 am, Leo Simons <LS...@schubergphilis.com> wrote:
>
>> On Aug 7, 2014, at 8:40 AM, Animesh Chaturvedi <an...@citrix.com> wrote:
>>>> (Like most of the internet...) I strongly believe using cherry 
>>>> picks as the basic tool for (release) branch management is one of 
>>>> the worst choices you can make.
>>>>
>>>> But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]
>>>>
>>> [Animesh] Leo I don't mind moving to merging branches rather than cherry-picking for technical reasons, but I am not sure cherry-picking is to blame entirely. Using it all the time caused the pain.
>>
>> Yes, I completely agree with that! It was a bit tongue-in-cheek, in fact the joke at the [1] reference...
>>
>>> [1] ... Using 'git cherry-pick' when there are actual cherries to 
>>> actually pick is fully endorsed by LSD Enterprises LTD.
>>> Picking things other than cherries voids warranty. ...
>>
>> ...tries to make the same point. I really should stop trying to be 
>> funny! More seriously,
>>
>>
>> Use distributed version control.
>> Commit early and often. Push often enough.
>> Strive for idempotent commits.
>> Write good commit messages.
>> Ask and give review liberally.
>> Keep history though rewriting some of it is ok.
>> Branch pre-emptively, except when you are sure you don’t need to.
>> Rebase when it is safe to do so.
>> Merge deliberately to combine branches.
>> Stabilize a branch before you merge from it.
>> Merge from the more stable onto the less stable branches.
>> Pick cherries from a less stable branch you won’t merge.
>> Know your tools.
>> Know when to break the rules.
>
> Very well said. May I add a solution to the cherry-picking problem, use a baseline protocol:
>
> 1. Once a release branch is cut out, all the committers and contributors “should” only work on release branch only. Only the new feature development and its enhancements/bugfixes should continue to land on master directly or merged from their respective branches.
>
> 2. The RMs or developers keep merging the release branch with fast forward only, this way we don’t have to cherry-pick from master to release branch but instead master gets all the good stuff from release branch and the release branch gets “more attention”.
>
> 3. If we somehow can reduce the release cycle timeline/length, the divergence will be less causing less conflicts/issues when following 1 and 2 above.
>
> Thoughts?
>
> Regards.
>
>>
>>
>> happy hacking,
>>
>>
>> Leo
>>
>
> 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] git workflow

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

I am not for grand proposals so I don't agree that we should first
make an inventory of all problems. The idea that we are going to do CI
on a staging branch I take for a fact for the moment. Given that I
would like to propose that we:

<proposal version='future'>
work on a 'development' branch.
merge on a nightly basis to a stable branch given the status of
'development' is 'passing'
branch release branches as 'x.y' from 'stable'
merge them back to 'stable' when stable and tag them as 'x.y.z'.
branch from 'x.y.z' when support branches need to be made as 'x.y' again
do not merge those back in principle but keep those around for users
to play with and because 'stable' and 'develop' continue
</proposal>

Whether we use gitflow is irrelevant in this. What other changes we do
as well. i.e. git pull instead of review board, using ci on
'development' or other branches.

Is this good enough for a vote?

regards,
Daan


On Thu, Aug 7, 2014 at 10:15 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hey,
>
> On 07-Aug-2014, at 9:22 am, Leo Simons <LS...@schubergphilis.com> wrote:
>
>> On Aug 7, 2014, at 8:40 AM, Animesh Chaturvedi <an...@citrix.com> wrote:
>>>> (Like most of the internet...) I strongly believe using cherry picks as the basic
>>>> tool for (release) branch management is one of the worst choices you can
>>>> make.
>>>>
>>>> But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]
>>>>
>>> [Animesh] Leo I don't mind moving to merging branches rather than cherry-picking for technical reasons, but I am not sure cherry-picking is to blame entirely. Using it all the time caused the pain.
>>
>> Yes, I completely agree with that! It was a bit tongue-in-cheek, in fact the joke at the [1] reference...
>>
>>> [1] ... Using 'git cherry-pick' when there are actual cherries
>>> to actually pick is fully endorsed by LSD Enterprises LTD.
>>> Picking things other than cherries voids warranty. ...
>>
>> ...tries to make the same point. I really should stop trying to be funny! More seriously,
>>
>>
>> Use distributed version control.
>> Commit early and often. Push often enough.
>> Strive for idempotent commits.
>> Write good commit messages.
>> Ask and give review liberally.
>> Keep history though rewriting some of it is ok.
>> Branch pre-emptively, except when you are sure you don’t need to.
>> Rebase when it is safe to do so.
>> Merge deliberately to combine branches.
>> Stabilize a branch before you merge from it.
>> Merge from the more stable onto the less stable branches.
>> Pick cherries from a less stable branch you won’t merge.
>> Know your tools.
>> Know when to break the rules.
>
> Very well said. May I add a solution to the cherry-picking problem, use a baseline protocol:
>
> 1. Once a release branch is cut out, all the committers and contributors “should” only work on release branch only. Only the new feature development and its enhancements/bugfixes should continue to land on master directly or merged from their respective branches.
>
> 2. The RMs or developers keep merging the release branch with fast forward only, this way we don’t have to cherry-pick from master to release branch but instead master gets all the good stuff from release branch and the release branch gets “more attention”.
>
> 3. If we somehow can reduce the release cycle timeline/length, the divergence will be less causing less conflicts/issues when following 1 and 2 above.
>
> Thoughts?
>
> Regards.
>
>>
>>
>> happy hacking,
>>
>>
>> Leo
>>
>
> 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] git workflow

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

Hey,

On 07-Aug-2014, at 9:22 am, Leo Simons <LS...@schubergphilis.com> wrote:

> On Aug 7, 2014, at 8:40 AM, Animesh Chaturvedi <an...@citrix.com> wrote:
>>> (Like most of the internet...) I strongly believe using cherry picks as the basic
>>> tool for (release) branch management is one of the worst choices you can
>>> make.
>>>
>>> But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]
>>>
>> [Animesh] Leo I don't mind moving to merging branches rather than cherry-picking for technical reasons, but I am not sure cherry-picking is to blame entirely. Using it all the time caused the pain.
>
> Yes, I completely agree with that! It was a bit tongue-in-cheek, in fact the joke at the [1] reference...
>
>> [1] ... Using 'git cherry-pick' when there are actual cherries
>> to actually pick is fully endorsed by LSD Enterprises LTD.
>> Picking things other than cherries voids warranty. ...
>
> ...tries to make the same point. I really should stop trying to be funny! More seriously,
>
>
> Use distributed version control.
> Commit early and often. Push often enough.
> Strive for idempotent commits.
> Write good commit messages.
> Ask and give review liberally.
> Keep history though rewriting some of it is ok.
> Branch pre-emptively, except when you are sure you don’t need to.
> Rebase when it is safe to do so.
> Merge deliberately to combine branches.
> Stabilize a branch before you merge from it.
> Merge from the more stable onto the less stable branches.
> Pick cherries from a less stable branch you won’t merge.
> Know your tools.
> Know when to break the rules.

Very well said. May I add a solution to the cherry-picking problem, use a baseline protocol:

1. Once a release branch is cut out, all the committers and contributors “should” only work on release branch only. Only the new feature development and its enhancements/bugfixes should continue to land on master directly or merged from their respective branches.

2. The RMs or developers keep merging the release branch with fast forward only, this way we don’t have to cherry-pick from master to release branch but instead master gets all the good stuff from release branch and the release branch gets “more attention”.

3. If we somehow can reduce the release cycle timeline/length, the divergence will be less causing less conflicts/issues when following 1 and 2 above.

Thoughts?

Regards.

>
>
> happy hacking,
>
>
> Leo
>

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] git workflow

[Leo Simons <LS...@schubergphilis.com>]

On Aug 7, 2014, at 8:40 AM, Animesh Chaturvedi <an...@citrix.com> wrote:
>> (Like most of the internet...) I strongly believe using cherry picks as the basic
>> tool for (release) branch management is one of the worst choices you can
>> make. 
>> 
>> But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]
>> 
> [Animesh] Leo I don't mind moving to merging branches rather than cherry-picking for technical reasons, but I am not sure cherry-picking is to blame entirely. Using it all the time caused the pain.

Yes, I completely agree with that! It was a bit tongue-in-cheek, in fact the joke at the [1] reference...

> [1] ... Using 'git cherry-pick' when there are actual cherries
> to actually pick is fully endorsed by LSD Enterprises LTD.
> Picking things other than cherries voids warranty. ...

...tries to make the same point. I really should stop trying to be funny! More seriously,


Use distributed version control.
Commit early and often. Push often enough.
Strive for idempotent commits.
Write good commit messages.
Ask and give review liberally.
Keep history though rewriting some of it is ok.
Branch pre-emptively, except when you are sure you don’t need to.
Rebase when it is safe to do so.
Merge deliberately to combine branches.
Stabilize a branch before you merge from it.
Merge from the more stable onto the less stable branches.
Pick cherries from a less stable branch you won’t merge.
Know your tools.
Know when to break the rules.


happy hacking,


Leo

RE: [VOTE] git workflow

[Animesh Chaturvedi <an...@citrix.com>]

> 
> (Like most of the internet...) I strongly believe using cherry picks as the basic
> tool for (release) branch management is one of the worst choices you can
> make. 
> 
> But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]
> 
[Animesh] Leo I don't mind moving to merging branches rather than cherry-picking for technical reasons, but I am not sure cherry-picking is to blame entirely. Using it all the time caused the pain. When Chip and I were running releases we started cherry-picks when we got closer to RC. I did not see cherry-pick as a big pain for 4.2 and 4.3 where I was the RM.  RM cannot scale if they are spending most of their time in cherry-picking or merging branches into release branch.  It needs to be done when they  are reasonably confident that the churn will be limited otherwise RM will get drowned in all these requests (be it cherry-pick or merge branch).  And also I have used cherry-pick with -x flag which appends "cherry-picked from ...'  to the original commit message in order to indicate which commit this change was cherry-picked from. 

Re: [VOTE] git workflow

[Leo Simons <LS...@schubergphilis.com>]

Hey Rohit,

On Aug 6, 2014, at 9:08 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
> The proposal thread warriors Rajani, Daan, Leo and others can comment and advise [on git flow]?

Hah, “thread warrior", I like that :-)

Cloudstack right now has, erm, some challenges when it comes to continuous integration and producing releases. Part of that is lack of (CI) resources, part of that is lack of discipline, part of that is lack of knowledge on how to best do these things, a big part of that is that cloudstack is a more complex software project than most so things that work elsewhere don’t work out of the box here.

In the end the best advice for workflow is always along the lines of
1) figure out how your tools can assist you the best to do the work you need to do
2) use those tools in a way everyone on the team understands
3) document recommended ways of working, but do not get in the way of the person doing the work
4) prefer slow but steadily evolving processes to radical change

Git is one particularly powerful tool, and more of the community learning more about its power and then applying that power to the cloudstack tree is a good thing.

Votes at apache are pretty crude tools to gauge consensus, it should be a goal of communities here to need them as little as possible. You are in a happy place when halfway through some [PROPOSAL] it turns out you’ve together already done all the work being proposed and the thread can just fizzle out.

Vetoes are perhaps the crudest tools available to a committer. They introduce a lot of friction into the consensus-building work. Vetoing a change to how git is (to be) used is an, erm, interesting approach, because in the end to cast a veto obliges you to know so much about git that you can plausibly defend that veto. It also obliges all other committers to educate themselves about both sides of the story, to assess whether to accept or challenge the veto. So, yesterday was a very interesting day for the cloudstack community. Seeing a veto on this stuff surprised me a lot. We have now forced ourselves to resolve something that’s difficult to resolve quickly and is normally best resolved one step at a time.

So, how do you do _that_? Well, for starters I suggest simply abandoning the [VOTE] and the associated -1s; resolving vetoes ‘properly' takes too much energy. Next, retract the [PROPOSAL]. Next, abandon thoughts like “I’m -1 on a whole range of things”, or “we must solve everything before we can change anything”. I think those are really counter productive. Then get back to consensus-building small steps at a time.

As for git flow. I’d advise to abandon it.

(Like most of the internet...) I strongly believe using cherry picks as the basic tool for (release) branch management is one of the worst choices you can make. It’s an ok approach with svn pre 1.5 (arguably better with svn than with git), but git has merge/rebase/—ff-only/—no-ff/-i and a whole lot more DVCS power that’s all there to help out with this stuff. I strongly believe cloudstack needs to change this practice. Unfortunately I don’t know how to do _that_ well while taking only one small step at a time, so this is a change that breaks the above rule #4. If you must break that rule, better to do it as far away from a major new release as possible (i.e. now is a particularly good time).

If you know lots about distributed version control and are a git expert I believe you don’t need git-flow. I see git-flow as training wheels, a mechanism to help people that are not seasoned git experts (like most of us) to get to grips with a better way of doing things. For me personally, I know quite a bit about git by now, but I am not at the point yet where I want to do everything without those training wheels.

I thought that git-flow could really help our team here: since it is so extensively documented, tool-supported, and pretty widely used, it is a healthy place to start from and can really help build a lot of knowledge and branch/merge confidence quickly. But it seems that it won’t help at all...it’s probably too big a step to take at once, and so now it’s introduced unneeded friction. Whoops! So, throw it out. I don’t mind :)

But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]


cheers,


Leo

[1] IANAL. YMMV. Product may contain nuts. Using 'git cherry-pick' when there are actual cherries to actually pick is fully endorsed by LSD Enterprises LTD. Picking things other than cherries voids warranty. LSD Enterprises LTD provides the Advice on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. [2]

[2] Don’t Panic.

Re: [VOTE] git workflow

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

Hi,

If it was not clear, let me re-state — just because I’m participating in this thread does not mean I fully support git-flow, or I am here to defend it.

The proposal thread warriors Rajani, Daan, Leo and others can comment and advise?

I like couple of good ideas in it, and I think it’s better than what we do, especially the baseline protocol. I want to take good stuff from it and adapt them to our workflow. As I see now, this won't change our process/workflow a lot or that it can stop bad commits or practices from happening in our repositories.

I’ve emailed git-flow’s author about raised issues, will keep everyone posted.

Cheers.

On 06-Aug-2014, at 8:29 pm, Alena Prokharchyk <Al...@citrix.com> wrote:
>
> On 8/6/14, 11:22 AM, "David Nalley" <da...@gnsa.us> wrote:
>
>> On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav <ro...@shapeblue.com>
>> wrote:
>>> Hi,
>>>
>>> On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk
>>> <Al...@citrix.com> wrote:
>>>
>>>> Rohit, thank you for the explanation. So we cut the maintenance release
>>>> from the master branch, not *develop as opposed to the major release
>>>> branch.
>>>>
>>>> One more open question. Its clear that we cut the maintenance release
>>>> from
>>>> the master branch, but what would be the right way to merge it back if
>>>> this is a maintenance release for say 4.2, and 4.4 is the top of the
>>>> master branch? Where would the 4.2.1 tag appear? It can¹t be on a top
>>>> of
>>>> 4.4
>>>
>>> You checkout a support branch from 4.2 tag (or for that matter you may
>>> keep the 4.2 release branch, it¹s same) for LTS/support.
>>> You tag 4.2.1 on the support branch. (it¹s the same way you would do
>>> like we do it now). I think git-flow is suitable for rolling releases
>>> and may not 100% work with our deployment/release process. One thing
>>> I¹ve suggested is shortening of our release cycles which can help.
>>>
>>
>> So I suspect that checking out a tag would work. I don't know that
>> once we create a tag, that we would be able to merge that back into
>> master. Especially true for maintenance releases. How and where would
>> we merge 4.5.1 back into master? Moreover, I don't see us getting out
>> of checking out the tag, and creating a branch to work in. That means
>> we'd delete a branch, check out a tag, create a branch, create a new
>> tag, delete a branch - and repeat.
>>
>> That said, we don't currently have rolling releases - and now you are
>> suggesting it may not 100% work. *sigh*
>
> Dave, you are right, we can¹t. There is no way to merge back minor
> releases back to master branch, and preserve the history. The model works
> only for rolling releases. So making master reflect release branch won¹t
> make sense in CS case.
>
>>
>>> The flow of commits/fixes/changes would follow the baseline protocol ‹
>>> from firm branch to soft branches chronologically, so if there is a bug
>>> on 4.2 release you fix it on 4.2 support branch and
>>> cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch and
>>> then to 4.4 support branch Š to 4.5 release branch to develop branch.
>>>
>>> I think git-flow assumes the releases will be chronological so you
>>> don¹t release 4.3.1 after 4.4 etc and you always progress? I¹m not sure.
>>> We can think of better ways of doing things, we can also learn from how
>>> other projects do it.
>>>
>>> Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be
>>> painful, that always felt to me like maintaining a whole different
>>> product. If we can do something about that, we¹re going to make a lot of
>>> people happy IMO.
>>>
>>>>
>>
>> So we've set the expectation that we'll follow SemVer - and adhering
>> to that is a good thing. Rolling releases are interesting, but we are
>> a long way from being able to do anything remotely close IMO.

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] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

On 8/6/14, 11:22 AM, "David Nalley" <da...@gnsa.us> wrote:

>On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav <ro...@shapeblue.com>
>wrote:
>> Hi,
>>
>> On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk
>><Al...@citrix.com> wrote:
>>
>>> Rohit, thank you for the explanation. So we cut the maintenance release
>>> from the master branch, not *develop as opposed to the major release
>>> branch.
>>>
>>> One more open question. Its clear that we cut the maintenance release
>>>from
>>> the master branch, but what would be the right way to merge it back if
>>> this is a maintenance release for say 4.2, and 4.4 is the top of the
>>> master branch? Where would the 4.2.1 tag appear? It can¹t be on a top
>>>of
>>> 4.4
>>
>> You checkout a support branch from 4.2 tag (or for that matter you may
>>keep the 4.2 release branch, it¹s same) for LTS/support.
>> You tag 4.2.1 on the support branch. (it¹s the same way you would do
>>like we do it now). I think git-flow is suitable for rolling releases
>>and may not 100% work with our deployment/release process. One thing
>>I¹ve suggested is shortening of our release cycles which can help.
>>
>
>So I suspect that checking out a tag would work. I don't know that
>once we create a tag, that we would be able to merge that back into
>master. Especially true for maintenance releases. How and where would
>we merge 4.5.1 back into master? Moreover, I don't see us getting out
>of checking out the tag, and creating a branch to work in. That means
>we'd delete a branch, check out a tag, create a branch, create a new
>tag, delete a branch - and repeat.
>
>That said, we don't currently have rolling releases - and now you are
>suggesting it may not 100% work. *sigh*

Dave, you are right, we can¹t. There is no way to merge back minor
releases back to master branch, and preserve the history. The model works
only for rolling releases. So making master reflect release branch won¹t
make sense in CS case.

>
>> The flow of commits/fixes/changes would follow the baseline protocol ‹
>>from firm branch to soft branches chronologically, so if there is a bug
>>on 4.2 release you fix it on 4.2 support branch and
>>cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch and
>>then to 4.4 support branch Š to 4.5 release branch to develop branch.
>>
>> I think git-flow assumes the releases will be chronological so you
>>don¹t release 4.3.1 after 4.4 etc and you always progress? I¹m not sure.
>> We can think of better ways of doing things, we can also learn from how
>>other projects do it.
>>
>> Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be
>>painful, that always felt to me like maintaining a whole different
>>product. If we can do something about that, we¹re going to make a lot of
>>people happy IMO.
>>
>>>
>
>So we've set the expectation that we'll follow SemVer - and adhering
>to that is a good thing. Rolling releases are interesting, but we are
>a long way from being able to do anything remotely close IMO.

Re: [VOTE] git workflow

[David Nalley <da...@gnsa.us>]

On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hi,
>
> On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk <Al...@citrix.com> wrote:
>
>> Rohit, thank you for the explanation. So we cut the maintenance release
>> from the master branch, not *develop as opposed to the major release
>> branch.
>>
>> One more open question. Its clear that we cut the maintenance release from
>> the master branch, but what would be the right way to merge it back if
>> this is a maintenance release for say 4.2, and 4.4 is the top of the
>> master branch? Where would the 4.2.1 tag appear? It can’t be on a top of
>> 4.4
>
> You checkout a support branch from 4.2 tag (or for that matter you may keep the 4.2 release branch, it’s same) for LTS/support.
> You tag 4.2.1 on the support branch. (it’s the same way you would do like we do it now). I think git-flow is suitable for rolling releases and may not 100% work with our deployment/release process. One thing I’ve suggested is shortening of our release cycles which can help.
>

So I suspect that checking out a tag would work. I don't know that
once we create a tag, that we would be able to merge that back into
master. Especially true for maintenance releases. How and where would
we merge 4.5.1 back into master? Moreover, I don't see us getting out
of checking out the tag, and creating a branch to work in. That means
we'd delete a branch, check out a tag, create a branch, create a new
tag, delete a branch - and repeat.

That said, we don't currently have rolling releases - and now you are
suggesting it may not 100% work. *sigh*

> The flow of commits/fixes/changes would follow the baseline protocol — from firm branch to soft branches chronologically, so if there is a bug on 4.2 release you fix it on 4.2 support branch and cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch and then to 4.4 support branch … to 4.5 release branch to develop branch.
>
> I think git-flow assumes the releases will be chronological so you don’t release 4.3.1 after 4.4 etc and you always progress? I’m not sure.
> We can think of better ways of doing things, we can also learn from how other projects do it.
>
> Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be painful, that always felt to me like maintaining a whole different product. If we can do something about that, we’re going to make a lot of people happy IMO.
>
>>

So we've set the expectation that we'll follow SemVer - and adhering
to that is a good thing. Rolling releases are interesting, but we are
a long way from being able to do anything remotely close IMO.

Re: [VOTE] git workflow

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

Hi,

On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk <Al...@citrix.com> wrote:

> Rohit, thank you for the explanation. So we cut the maintenance release
> from the master branch, not *develop as opposed to the major release
> branch.
>
> One more open question. Its clear that we cut the maintenance release from
> the master branch, but what would be the right way to merge it back if
> this is a maintenance release for say 4.2, and 4.4 is the top of the
> master branch? Where would the 4.2.1 tag appear? It can’t be on a top of
> 4.4

You checkout a support branch from 4.2 tag (or for that matter you may keep the 4.2 release branch, it’s same) for LTS/support.
You tag 4.2.1 on the support branch. (it’s the same way you would do like we do it now). I think git-flow is suitable for rolling releases and may not 100% work with our deployment/release process. One thing I’ve suggested is shortening of our release cycles which can help.

The flow of commits/fixes/changes would follow the baseline protocol — from firm branch to soft branches chronologically, so if there is a bug on 4.2 release you fix it on 4.2 support branch and cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch and then to 4.4 support branch … to 4.5 release branch to develop branch.

I think git-flow assumes the releases will be chronological so you don’t release 4.3.1 after 4.4 etc and you always progress? I’m not sure.
We can think of better ways of doing things, we can also learn from how other projects do it.

Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be painful, that always felt to me like maintaining a whole different product. If we can do something about that, we’re going to make a lot of people happy IMO.

>
>
> All the above should be documented in the proposal. The original proposal
> didn’t mention anything about how we are going to do maintenance branches.
> And we were originally thinking about leaving the release branches around.
>
> Thanks,
> Alena.
>
>
> On 8/6/14, 10:16 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>
>>
>> On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk
>> <Al...@citrix.com> wrote:
>>
>>> Why implement something that doesn¹t serve any practical purpose for
>>> CS??
>>> We should adopt only things that would address current CS problems -
>>> regressions, unstable releases, etc. That would mean - running the
>>> automation (CI, BVT) on *develop branch, cut the *fix branches for hot
>>> fixes/critical/feature bugs only and run BVT on them before merging to
>>> *develop; merge only stable code from *develop to master branch.
>>>
>>> There would be no use for master branch if it reflects the latest
>>> release
>>> branch, which will always be present in CS model as opposed to what
>>> original article suggests. Below the explanation from the other email
>>> thread on why the release branches can¹t be removed in CS model:
>>>
>>> Rohit:
>>> ================
>>>
>>> "IMO We ³should" remove the release branches when done. Instead there
>>> is a
>>> support workflow with git-flow (see support
>>> http://yakiloo.com/getting-started-git-flow/) and also in the tooling
>>> (git
>>> flow support etc. though experimental).²
>>>
>>> Alena:
>>> ==========
>>> If we remove the release branches, how are we going to handle
>>> maintenance
>>> releases for older versions of the code? It wouldn¹t work as its
>>> impossible to cut a maintenance release from develop branch.
>>
>> When you merge --no-ff a release/any branch on master/target branch, the
>> version history stays with it.
>> Not only we merge it on master, we do a tag on it as well. Now to get the
>> history/branch back you can always checkout the tag: git checkout <tag>
>> and see the history:
>> git log --graph --decorate --pretty=oneline --abbrev-commit —all
>>
>> So, it’s safe to delete a branch when it’s merged to a target/master
>> branch.
>> If you have never deleted a feature branch once it was merged, you should
>> try and see for yourself. At the end of the day, git is all but link-list
>> logic at the core. The branch too tracks just the HEAD, if you’ve
>> refs/tag/sha of a branch you can checkout to get the branch back.
>>
>> When a branch is merged, git allows you do delete the branch with: git
>> branch -d <release>, if branch is not merged you’ve to force it with -D:
>> git branch -D <release>
>> To cut a maintenance release from a release version, all you’ll have to
>> do it:
>> git checkout -b <support-branch> <tag>
>>
>> HTH.
>>
>>> I think the model the article proposes, fits the products like SAS, when
>>> there are no maintenance releases and support is provided just for the
>>> latest release.  Then of course, to get the latest stable release, it
>>> would make sense to access master branch which is always stable. In case
>>> when multiple releases are being maintained at the same time - like CS -
>>> it would make sense to keep release branches. Otherwise how are you
>>> going
>>> to handle this situation:
>>>
>>> 4.2, 4.3 and 4.4 are released
>>> Master reflects 4.4
>>> Maintenance 4.2.1 and 4.3.1 releases are needed
>>>
>>> Questions:
>>> How do you create those releases, from what branch?
>>> How do you merge and tag them into master branch considering that the
>>> latest version there is 4.4?
>>>
>>> Thanks,
>>> Alena.
>>>
>>>
>>>
>>>
>>> On 8/5/14, 11:36 PM, "Daan Hoogland" <da...@gmail.com> wrote:
>>>
>>>> Exactly Rajani, and other solutions are possible. The issue is not how
>>>> branches are called ;)
>>>>
>>>> On Wed, Aug 6, 2014 at 8:29 AM, Rajani Karuturi
>>>> <Ra...@citrix.com> wrote:
>>>>> I am just wondering if the shift to a new develop branch is causing
>>>>> the
>>>>> problems. Its a simple branch shift and should be no different from
>>>>> the
>>>>> current master.
>>>>>
>>>>> may be we should leave the master as is and create a Œstable' branch
>>>>> which would act like master in git-flow ?
>>>>>
>>>>> ie)
>>>>> ACS master -> develop in git-flow
>>>>> ACS stable -> master in git-flow
>>>>>
>>>>>
>>>>> ~Rajani
>>>>>
>>>>>
>>>>>
>>>>> On 06-Aug-2014, at 10:56 am, Daan Hoogland <da...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello devs and especially committters,
>>>>>>
>>>>>> I see some -1s coming by, days after the vote was closed. That is
>>>>>> disturbing as it means we accepted a proposal that will not be
>>>>>> supported by the community. So let me try to find that support in
>>>>>> hindsight;
>>>>>>
>>>>>> The argument of Animesh that we are shifting the burden from one
>>>>>> branch to another is real and present danger. I share his concern. It
>>>>>> is not the only feature of this proposal and in it self does not
>>>>>> warrant a -1. It does not worsen the situation at hand or add to our
>>>>>> workload in any way. If there is no advantage to you and no
>>>>>> disadvantage either then why -1 something that others do find useful?
>>>>>> This is 'kind of' a rhetorical question. It is a real concern,
>>>>>> however
>>>>>> though not the biggest at this moment.
>>>>>>
>>>>>> branching is recommended but as people are rightfully wondering
>>>>>> "should I make a branch for a single line fix". I would, probably but
>>>>>> maybe not always. That doesn't mean you must. In case you are making
>>>>>> a
>>>>>> fix on a release then yes you do. It is how the git-flow workflow
>>>>>> goes.
>>>>>>
>>>>>> Committers can merge and commit where ever they feel the need. That
>>>>>> doesn't exempt them from thinking if it is a good idea. It doesn't
>>>>>> now
>>>>>> and it won't in the future. Doing what your boss tells you to do can
>>>>>> be a crime!
>>>>>>
>>>>>> Reverting something should only be done when the code that is a
>>>>>> culprit has been identified. Reverting a big change or even a bunch
>>>>>> of
>>>>>> changes is a cowards way out. We shouldn't do it now or using
>>>>>> gitflow.
>>>>>> It is not really related to git flow or its use. So we shouldn't
>>>>>> penalize developers that didn't cause a problem or ones that did. We
>>>>>> should help them help us make a better system.
>>>>>>
>>>>>> The question of why this process isn't implemented on master is
>>>>>> valid.
>>>>>> It could. It isn't however. It is a choice the authors of gitflow
>>>>>> made. I think it is not really the time anymore to be nitpicking
>>>>>> about
>>>>>> this. Unless we find a very valid reason to alter the accepted
>>>>>> proposal we should all try and implement it as good as possible. I
>>>>>> have been RM for 4.4.0 and one thing I don't want anymore is people
>>>>>> share a 4.4-forward to cherry-pick commits from. It caused me a lot
>>>>>> of
>>>>>> headaches.
>>>>>>
>>>>>> The release is what drives the merges back to master according to
>>>>>> git-flow. We can decide that we define a number of prerelease dates
>>>>>> at
>>>>>> which we merge as well. We don't have to do it at that date but can
>>>>>> decide to do that the next day or week as well. This would kind of
>>>>>> resemble Alena's #1 (as opposed to the more pure gitflow #2). An
>>>>>> argument for #2 is that I don't think every customer greps the rpms
>>>>>> for some release. I know our operators at Schuberg Philis investigate
>>>>>> the code and check it out from git. They like to compare release and
>>>>>> look at the latest easily. just checking out master would be very
>>>>>> convenient for them. Of course they can check out a branch as well.
>>>>>> But I doubt if they know exactly what to checkout then. I usually see
>>>>>> them just look at the latest for a branch.
>>>>>>
>>>>>> All in all, I am very skeptic on whether this will work as planned.
>>>>>> It
>>>>>> is us who need to work neatly and only if we do that we can help
>>>>>> ourselves with improving our process. I do feel that the present way
>>>>>> of working, mainly the use forward branches but in general the lack
>>>>>> of
>>>>>> using branches to test individual changes, is hindering us in doing
>>>>>> releases. The proposal at hand is very good but can only work if
>>>>>> supported by the people that need to work with it. It doesn't do our
>>>>>> release process for us. We still need to do it and not just program
>>>>>> some code and check it in. That will never work in any process. Your
>>>>>> code is not done until somebody somewhere finds it worth running it
>>>>>> in
>>>>>> a production environment. So let's keep discussing and educating each
>>>>>> other.
>>>>>>
>>>>>> done ranting, feel free to react or contact me in person
>>>>>> Daan
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <te...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle
>>>>>>>> <Pr...@citrix.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I fail to understand how will this model help us with the
>>>>>>>>> maintenance
>>>>>>>>> releases?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> That's what gitflow support branches is for.
>>>>>>>> I find this quite descriptive:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH
>>>>>>>> 06
>>>>>>>> CuKT0J
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> For CloudStack we also keep working on prior releases and ship out
>>>>>>>>> maintenance releases.
>>>>>>>>> I suppose we will be cutting the maintenance releases from the
>>>>>>>>> release
>>>>>>>>> branches? So we will have to keep around the release branches for
>>>>>>>>> that
>>>>>>>>> purpose.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I've asked earlier, but what is the policy on old releases? How
>>>>>>>> long
>>>>>>>> do we
>>>>>>>> support them?
>>>>>>>>
>>>>>>>>
>>>>>>> Today (e.g. subject to change) we claim to support as a community
>>>>>>> the
>>>>>>> two
>>>>>>> most recent feature releases. (for instance, we just stopped support
>>>>>>> the
>>>>>>> 4.2.x line with the release of 4.4.0, and currently support 4.3.x
>>>>>>> and
>>>>>>> 4.4.x) We support those feature releases with bug fix releases that
>>>>>>> contain
>>>>>>> no additional functionality.
>>>>>>>
>>>>>>> --David
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daan
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Daan
>>>
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.yadav@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design &
>> Build<http://shapeblue.com/iaas-cloud-design-and-build//>
>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>> CloudStack Infrastructure
>> Support<http://shapeblue.com/cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training
>> Courses<http://shapeblue.com/cloudstack-training/>
>>
>> This email and any attachments to it may be confidential and are intended
>> solely for the use of the individual to whom it is addressed. Any views
>> or opinions expressed are solely those of the author and do not
>> necessarily represent those of Shape Blue Ltd or related companies. If
>> you are not the intended recipient of this email, you must neither take
>> any action based upon its contents, nor copy or show it to anyone. Please
>> contact the sender if you believe you have received this email in error.
>> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>> Services India LLP is a company incorporated in India and is operated
>> under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
>> a company incorporated in Brasil and is operated under license from Shape
>> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
>> South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
>> is a registered trademark.
>

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] git workflow

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

On Wed, Aug 6, 2014 at 7:30 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> Rohit, thank you for the explanation. So we cut the maintenance release
> from the master branch, not *develop as opposed to the major release
> branch.
>
>
Here's what happens if you want to create a support (ie maintenance
release) branch, in this example I'll use 4.3.1 as example maintenance
version number.

> git checkout 4.3.0 ( this should be the release tag)
> git checkout -b support/4.3.x
> git checkout -b hotfix/4.3.1

... make your fix, then:

> git checkout support/4.3.x
> git merge hotfix/4.3.1
> git branch -d hotfix/4.3.1
> git tag 4.3.1


If you install the gitflow tools you don't do all this yourself, instead
you would do this:

> git flow support start 4.3.x 4.3.0
> git flow hotfix start 4.3.1 support/4.3.x

... make changes then:

> git flow hotfix finish 4.3.1

As you can see the support/4.3.x branch persists, and a subsequent release
4.3.2 would be branched off that.


One more open question. Its clear that we cut the maintenance release from
> the master branch, but what would be the right way to merge it back if
> this is a maintenance release for say 4.2, and 4.4 is the top of the
> master branch? Where would the 4.2.1 tag appear? It can’t be on a top of
> 4.4
>
>
You don't merge it back to master unless the maintenance would be the
latest release. (i'm not even sure if you do it then)



>
> All the above should be documented in the proposal. The original proposal
> didn’t mention anything about how we are going to do maintenance branches.
> And we were originally thinking about leaving the release branches around.
>
>
Gitflow has a concept for this, it's called support branch/releases.

-- 
Erik

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Rohit, thank you for the explanation. So we cut the maintenance release
from the master branch, not *develop as opposed to the major release
branch.

One more open question. Its clear that we cut the maintenance release from
the master branch, but what would be the right way to merge it back if
this is a maintenance release for say 4.2, and 4.4 is the top of the
master branch? Where would the 4.2.1 tag appear? It can’t be on a top of
4.4


All the above should be documented in the proposal. The original proposal
didn’t mention anything about how we are going to do maintenance branches.
And we were originally thinking about leaving the release branches around.

Thanks,
Alena.


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

>
>On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk
><Al...@citrix.com> wrote:
>
>> Why implement something that doesn¹t serve any practical purpose for
>>CS??
>> We should adopt only things that would address current CS problems -
>> regressions, unstable releases, etc. That would mean - running the
>> automation (CI, BVT) on *develop branch, cut the *fix branches for hot
>> fixes/critical/feature bugs only and run BVT on them before merging to
>> *develop; merge only stable code from *develop to master branch.
>>
>> There would be no use for master branch if it reflects the latest
>>release
>> branch, which will always be present in CS model as opposed to what
>> original article suggests. Below the explanation from the other email
>> thread on why the release branches can¹t be removed in CS model:
>>
>> Rohit:
>> ================
>>
>> "IMO We ³should" remove the release branches when done. Instead there
>>is a
>> support workflow with git-flow (see support
>> http://yakiloo.com/getting-started-git-flow/) and also in the tooling
>>(git
>> flow support etc. though experimental).²
>>
>> Alena:
>> ==========
>> If we remove the release branches, how are we going to handle
>>maintenance
>> releases for older versions of the code? It wouldn¹t work as its
>> impossible to cut a maintenance release from develop branch.
>
>When you merge --no-ff a release/any branch on master/target branch, the
>version history stays with it.
>Not only we merge it on master, we do a tag on it as well. Now to get the
>history/branch back you can always checkout the tag: git checkout <tag>
>and see the history:
>git log --graph --decorate --pretty=oneline --abbrev-commit —all
>
>So, it’s safe to delete a branch when it’s merged to a target/master
>branch.
>If you have never deleted a feature branch once it was merged, you should
>try and see for yourself. At the end of the day, git is all but link-list
>logic at the core. The branch too tracks just the HEAD, if you’ve
>refs/tag/sha of a branch you can checkout to get the branch back.
>
>When a branch is merged, git allows you do delete the branch with: git
>branch -d <release>, if branch is not merged you’ve to force it with -D:
>git branch -D <release>
>To cut a maintenance release from a release version, all you’ll have to
>do it:
>git checkout -b <support-branch> <tag>
>
>HTH.
>
>> I think the model the article proposes, fits the products like SAS, when
>> there are no maintenance releases and support is provided just for the
>> latest release.  Then of course, to get the latest stable release, it
>> would make sense to access master branch which is always stable. In case
>> when multiple releases are being maintained at the same time - like CS -
>> it would make sense to keep release branches. Otherwise how are you
>>going
>> to handle this situation:
>>
>> 4.2, 4.3 and 4.4 are released
>> Master reflects 4.4
>> Maintenance 4.2.1 and 4.3.1 releases are needed
>>
>> Questions:
>> How do you create those releases, from what branch?
>> How do you merge and tag them into master branch considering that the
>> latest version there is 4.4?
>>
>> Thanks,
>> Alena.
>>
>>
>>
>>
>> On 8/5/14, 11:36 PM, "Daan Hoogland" <da...@gmail.com> wrote:
>>
>>> Exactly Rajani, and other solutions are possible. The issue is not how
>>> branches are called ;)
>>>
>>> On Wed, Aug 6, 2014 at 8:29 AM, Rajani Karuturi
>>> <Ra...@citrix.com> wrote:
>>>> I am just wondering if the shift to a new develop branch is causing
>>>>the
>>>> problems. Its a simple branch shift and should be no different from
>>>>the
>>>> current master.
>>>>
>>>> may be we should leave the master as is and create a Œstable' branch
>>>> which would act like master in git-flow ?
>>>>
>>>> ie)
>>>> ACS master -> develop in git-flow
>>>> ACS stable -> master in git-flow
>>>>
>>>>
>>>> ~Rajani
>>>>
>>>>
>>>>
>>>> On 06-Aug-2014, at 10:56 am, Daan Hoogland <da...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hello devs and especially committters,
>>>>>
>>>>> I see some -1s coming by, days after the vote was closed. That is
>>>>> disturbing as it means we accepted a proposal that will not be
>>>>> supported by the community. So let me try to find that support in
>>>>> hindsight;
>>>>>
>>>>> The argument of Animesh that we are shifting the burden from one
>>>>> branch to another is real and present danger. I share his concern. It
>>>>> is not the only feature of this proposal and in it self does not
>>>>> warrant a -1. It does not worsen the situation at hand or add to our
>>>>> workload in any way. If there is no advantage to you and no
>>>>> disadvantage either then why -1 something that others do find useful?
>>>>> This is 'kind of' a rhetorical question. It is a real concern,
>>>>>however
>>>>> though not the biggest at this moment.
>>>>>
>>>>> branching is recommended but as people are rightfully wondering
>>>>> "should I make a branch for a single line fix". I would, probably but
>>>>> maybe not always. That doesn't mean you must. In case you are making
>>>>>a
>>>>> fix on a release then yes you do. It is how the git-flow workflow
>>>>> goes.
>>>>>
>>>>> Committers can merge and commit where ever they feel the need. That
>>>>> doesn't exempt them from thinking if it is a good idea. It doesn't
>>>>>now
>>>>> and it won't in the future. Doing what your boss tells you to do can
>>>>> be a crime!
>>>>>
>>>>> Reverting something should only be done when the code that is a
>>>>> culprit has been identified. Reverting a big change or even a bunch
>>>>>of
>>>>> changes is a cowards way out. We shouldn't do it now or using
>>>>>gitflow.
>>>>> It is not really related to git flow or its use. So we shouldn't
>>>>> penalize developers that didn't cause a problem or ones that did. We
>>>>> should help them help us make a better system.
>>>>>
>>>>> The question of why this process isn't implemented on master is
>>>>>valid.
>>>>> It could. It isn't however. It is a choice the authors of gitflow
>>>>> made. I think it is not really the time anymore to be nitpicking
>>>>>about
>>>>> this. Unless we find a very valid reason to alter the accepted
>>>>> proposal we should all try and implement it as good as possible. I
>>>>> have been RM for 4.4.0 and one thing I don't want anymore is people
>>>>> share a 4.4-forward to cherry-pick commits from. It caused me a lot
>>>>>of
>>>>> headaches.
>>>>>
>>>>> The release is what drives the merges back to master according to
>>>>> git-flow. We can decide that we define a number of prerelease dates
>>>>>at
>>>>> which we merge as well. We don't have to do it at that date but can
>>>>> decide to do that the next day or week as well. This would kind of
>>>>> resemble Alena's #1 (as opposed to the more pure gitflow #2). An
>>>>> argument for #2 is that I don't think every customer greps the rpms
>>>>> for some release. I know our operators at Schuberg Philis investigate
>>>>> the code and check it out from git. They like to compare release and
>>>>> look at the latest easily. just checking out master would be very
>>>>> convenient for them. Of course they can check out a branch as well.
>>>>> But I doubt if they know exactly what to checkout then. I usually see
>>>>> them just look at the latest for a branch.
>>>>>
>>>>> All in all, I am very skeptic on whether this will work as planned.
>>>>>It
>>>>> is us who need to work neatly and only if we do that we can help
>>>>> ourselves with improving our process. I do feel that the present way
>>>>> of working, mainly the use forward branches but in general the lack
>>>>>of
>>>>> using branches to test individual changes, is hindering us in doing
>>>>> releases. The proposal at hand is very good but can only work if
>>>>> supported by the people that need to work with it. It doesn't do our
>>>>> release process for us. We still need to do it and not just program
>>>>> some code and check it in. That will never work in any process. Your
>>>>> code is not done until somebody somewhere finds it worth running it
>>>>>in
>>>>> a production environment. So let's keep discussing and educating each
>>>>> other.
>>>>>
>>>>> done ranting, feel free to react or contact me in person
>>>>> Daan
>>>>>
>>>>>
>>>>> On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <te...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle
>>>>>>> <Pr...@citrix.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I fail to understand how will this model help us with the
>>>>>>>> maintenance
>>>>>>>> releases?
>>>>>>>>
>>>>>>>>
>>>>>>> That's what gitflow support branches is for.
>>>>>>> I find this quite descriptive:
>>>>>>>
>>>>>>>
>>>>>>> 
>>>>>>>https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH
>>>>>>>06
>>>>>>> CuKT0J
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> For CloudStack we also keep working on prior releases and ship out
>>>>>>>> maintenance releases.
>>>>>>>> I suppose we will be cutting the maintenance releases from the
>>>>>>>> release
>>>>>>>> branches? So we will have to keep around the release branches for
>>>>>>>> that
>>>>>>>> purpose.
>>>>>>>>
>>>>>>>>
>>>>>>> I've asked earlier, but what is the policy on old releases? How
>>>>>>>long
>>>>>>> do we
>>>>>>> support them?
>>>>>>>
>>>>>>>
>>>>>> Today (e.g. subject to change) we claim to support as a community
>>>>>>the
>>>>>> two
>>>>>> most recent feature releases. (for instance, we just stopped support
>>>>>> the
>>>>>> 4.2.x line with the release of 4.4.0, and currently support 4.3.x
>>>>>>and
>>>>>> 4.4.x) We support those feature releases with bug fix releases that
>>>>>> contain
>>>>>> no additional functionality.
>>>>>>
>>>>>> --David
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Daan
>>>>
>>>
>>>
>>>
>>> --
>>> Daan
>>
>
>Regards,
>Rohit Yadav
>Software Architect, ShapeBlue
>M. +41 779015219 | rohit.yadav@shapeblue.com
>Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
>Find out more about ShapeBlue and our range of CloudStack related services
>
>IaaS Cloud Design &
>Build<http://shapeblue.com/iaas-cloud-design-and-build//>
>CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>CloudStack Infrastructure
>Support<http://shapeblue.com/cloudstack-infrastructure-support/>
>CloudStack Bootcamp Training
>Courses<http://shapeblue.com/cloudstack-training/>
>
>This email and any attachments to it may be confidential and are intended
>solely for the use of the individual to whom it is addressed. Any views
>or opinions expressed are solely those of the author and do not
>necessarily represent those of Shape Blue Ltd or related companies. If
>you are not the intended recipient of this email, you must neither take
>any action based upon its contents, nor copy or show it to anyone. Please
>contact the sender if you believe you have received this email in error.
>Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>Services India LLP is a company incorporated in India and is operated
>under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
>a company incorporated in Brasil and is operated under license from Shape
>Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
>South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
>is a registered trademark.

Re: [VOTE] git workflow

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

On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk <Al...@citrix.com> wrote:

> Why implement something that doesn¹t serve any practical purpose for CS??
> We should adopt only things that would address current CS problems -
> regressions, unstable releases, etc. That would mean - running the
> automation (CI, BVT) on *develop branch, cut the *fix branches for hot
> fixes/critical/feature bugs only and run BVT on them before merging to
> *develop; merge only stable code from *develop to master branch.
>
> There would be no use for master branch if it reflects the latest release
> branch, which will always be present in CS model as opposed to what
> original article suggests. Below the explanation from the other email
> thread on why the release branches can¹t be removed in CS model:
>
> Rohit:
> ================
>
> "IMO We ³should" remove the release branches when done. Instead there is a
> support workflow with git-flow (see support
> http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git
> flow support etc. though experimental).²
>
> Alena:
> ==========
> If we remove the release branches, how are we going to handle maintenance
> releases for older versions of the code? It wouldn¹t work as its
> impossible to cut a maintenance release from develop branch.

When you merge --no-ff a release/any branch on master/target branch, the version history stays with it.
Not only we merge it on master, we do a tag on it as well. Now to get the history/branch back you can always checkout the tag: git checkout <tag> and see the history:
git log --graph --decorate --pretty=oneline --abbrev-commit —all

So, it’s safe to delete a branch when it’s merged to a target/master branch.
If you have never deleted a feature branch once it was merged, you should try and see for yourself. At the end of the day, git is all but link-list logic at the core. The branch too tracks just the HEAD, if you’ve refs/tag/sha of a branch you can checkout to get the branch back.

When a branch is merged, git allows you do delete the branch with: git branch -d <release>, if branch is not merged you’ve to force it with -D: git branch -D <release>
To cut a maintenance release from a release version, all you’ll have to do it:
git checkout -b <support-branch> <tag>

HTH.

> I think the model the article proposes, fits the products like SAS, when
> there are no maintenance releases and support is provided just for the
> latest release.  Then of course, to get the latest stable release, it
> would make sense to access master branch which is always stable. In case
> when multiple releases are being maintained at the same time - like CS -
> it would make sense to keep release branches. Otherwise how are you going
> to handle this situation:
>
> 4.2, 4.3 and 4.4 are released
> Master reflects 4.4
> Maintenance 4.2.1 and 4.3.1 releases are needed
>
> Questions:
> How do you create those releases, from what branch?
> How do you merge and tag them into master branch considering that the
> latest version there is 4.4?
>
> Thanks,
> Alena.
>
>
>
>
> On 8/5/14, 11:36 PM, "Daan Hoogland" <da...@gmail.com> wrote:
>
>> Exactly Rajani, and other solutions are possible. The issue is not how
>> branches are called ;)
>>
>> On Wed, Aug 6, 2014 at 8:29 AM, Rajani Karuturi
>> <Ra...@citrix.com> wrote:
>>> I am just wondering if the shift to a new develop branch is causing the
>>> problems. Its a simple branch shift and should be no different from the
>>> current master.
>>>
>>> may be we should leave the master as is and create a Œstable' branch
>>> which would act like master in git-flow ?
>>>
>>> ie)
>>> ACS master -> develop in git-flow
>>> ACS stable -> master in git-flow
>>>
>>>
>>> ~Rajani
>>>
>>>
>>>
>>> On 06-Aug-2014, at 10:56 am, Daan Hoogland <da...@gmail.com>
>>> wrote:
>>>
>>>> Hello devs and especially committters,
>>>>
>>>> I see some -1s coming by, days after the vote was closed. That is
>>>> disturbing as it means we accepted a proposal that will not be
>>>> supported by the community. So let me try to find that support in
>>>> hindsight;
>>>>
>>>> The argument of Animesh that we are shifting the burden from one
>>>> branch to another is real and present danger. I share his concern. It
>>>> is not the only feature of this proposal and in it self does not
>>>> warrant a -1. It does not worsen the situation at hand or add to our
>>>> workload in any way. If there is no advantage to you and no
>>>> disadvantage either then why -1 something that others do find useful?
>>>> This is 'kind of' a rhetorical question. It is a real concern, however
>>>> though not the biggest at this moment.
>>>>
>>>> branching is recommended but as people are rightfully wondering
>>>> "should I make a branch for a single line fix". I would, probably but
>>>> maybe not always. That doesn't mean you must. In case you are making a
>>>> fix on a release then yes you do. It is how the git-flow workflow
>>>> goes.
>>>>
>>>> Committers can merge and commit where ever they feel the need. That
>>>> doesn't exempt them from thinking if it is a good idea. It doesn't now
>>>> and it won't in the future. Doing what your boss tells you to do can
>>>> be a crime!
>>>>
>>>> Reverting something should only be done when the code that is a
>>>> culprit has been identified. Reverting a big change or even a bunch of
>>>> changes is a cowards way out. We shouldn't do it now or using gitflow.
>>>> It is not really related to git flow or its use. So we shouldn't
>>>> penalize developers that didn't cause a problem or ones that did. We
>>>> should help them help us make a better system.
>>>>
>>>> The question of why this process isn't implemented on master is valid.
>>>> It could. It isn't however. It is a choice the authors of gitflow
>>>> made. I think it is not really the time anymore to be nitpicking about
>>>> this. Unless we find a very valid reason to alter the accepted
>>>> proposal we should all try and implement it as good as possible. I
>>>> have been RM for 4.4.0 and one thing I don't want anymore is people
>>>> share a 4.4-forward to cherry-pick commits from. It caused me a lot of
>>>> headaches.
>>>>
>>>> The release is what drives the merges back to master according to
>>>> git-flow. We can decide that we define a number of prerelease dates at
>>>> which we merge as well. We don't have to do it at that date but can
>>>> decide to do that the next day or week as well. This would kind of
>>>> resemble Alena's #1 (as opposed to the more pure gitflow #2). An
>>>> argument for #2 is that I don't think every customer greps the rpms
>>>> for some release. I know our operators at Schuberg Philis investigate
>>>> the code and check it out from git. They like to compare release and
>>>> look at the latest easily. just checking out master would be very
>>>> convenient for them. Of course they can check out a branch as well.
>>>> But I doubt if they know exactly what to checkout then. I usually see
>>>> them just look at the latest for a branch.
>>>>
>>>> All in all, I am very skeptic on whether this will work as planned. It
>>>> is us who need to work neatly and only if we do that we can help
>>>> ourselves with improving our process. I do feel that the present way
>>>> of working, mainly the use forward branches but in general the lack of
>>>> using branches to test individual changes, is hindering us in doing
>>>> releases. The proposal at hand is very good but can only work if
>>>> supported by the people that need to work with it. It doesn't do our
>>>> release process for us. We still need to do it and not just program
>>>> some code and check it in. That will never work in any process. Your
>>>> code is not done until somebody somewhere finds it worth running it in
>>>> a production environment. So let's keep discussing and educating each
>>>> other.
>>>>
>>>> done ranting, feel free to react or contact me in person
>>>> Daan
>>>>
>>>>
>>>> On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <da...@gnsa.us> wrote:
>>>>> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <te...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle
>>>>>> <Pr...@citrix.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I fail to understand how will this model help us with the
>>>>>>> maintenance
>>>>>>> releases?
>>>>>>>
>>>>>>>
>>>>>> That's what gitflow support branches is for.
>>>>>> I find this quite descriptive:
>>>>>>
>>>>>>
>>>>>> https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06
>>>>>> CuKT0J
>>>>>>
>>>>>>
>>>>>>
>>>>>>> For CloudStack we also keep working on prior releases and ship out
>>>>>>> maintenance releases.
>>>>>>> I suppose we will be cutting the maintenance releases from the
>>>>>>> release
>>>>>>> branches? So we will have to keep around the release branches for
>>>>>>> that
>>>>>>> purpose.
>>>>>>>
>>>>>>>
>>>>>> I've asked earlier, but what is the policy on old releases? How long
>>>>>> do we
>>>>>> support them?
>>>>>>
>>>>>>
>>>>> Today (e.g. subject to change) we claim to support as a community the
>>>>> two
>>>>> most recent feature releases. (for instance, we just stopped support
>>>>> the
>>>>> 4.2.x line with the release of 4.4.0, and currently support 4.3.x and
>>>>> 4.4.x) We support those feature releases with bug fix releases that
>>>>> contain
>>>>> no additional functionality.
>>>>>
>>>>> --David
>>>>
>>>>
>>>>
>>>> --
>>>> Daan
>>>
>>
>>
>>
>> --
>> Daan
>

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [VOTE] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Why implement something that doesn¹t serve any practical purpose for CS??
We should adopt only things that would address current CS problems -
regressions, unstable releases, etc. That would mean - running the
automation (CI, BVT) on *develop branch, cut the *fix branches for hot
fixes/critical/feature bugs only and run BVT on them before merging to
*develop; merge only stable code from *develop to master branch.

There would be no use for master branch if it reflects the latest release
branch, which will always be present in CS model as opposed to what
original article suggests. Below the explanation from the other email
thread on why the release branches can¹t be removed in CS model:

Rohit:
================

"IMO We ³should" remove the release branches when done. Instead there is a
support workflow with git-flow (see support
http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git
flow support etc. though experimental).²

Alena:
==========
If we remove the release branches, how are we going to handle maintenance
releases for older versions of the code? It wouldn¹t work as its
impossible to cut a maintenance release from develop branch.

I think the model the article proposes, fits the products like SAS, when
there are no maintenance releases and support is provided just for the
latest release.  Then of course, to get the latest stable release, it
would make sense to access master branch which is always stable. In case
when multiple releases are being maintained at the same time - like CS -
it would make sense to keep release branches. Otherwise how are you going
to handle this situation:

4.2, 4.3 and 4.4 are released
Master reflects 4.4
Maintenance 4.2.1 and 4.3.1 releases are needed

Questions:
How do you create those releases, from what branch?
How do you merge and tag them into master branch considering that the
latest version there is 4.4?

Thanks,
Alena.




On 8/5/14, 11:36 PM, "Daan Hoogland" <da...@gmail.com> wrote:

>Exactly Rajani, and other solutions are possible. The issue is not how
>branches are called ;)
>
>On Wed, Aug 6, 2014 at 8:29 AM, Rajani Karuturi
><Ra...@citrix.com> wrote:
>> I am just wondering if the shift to a new develop branch is causing the
>>problems. Its a simple branch shift and should be no different from the
>>current master.
>>
>> may be we should leave the master as is and create a Œstable' branch
>>which would act like master in git-flow ?
>>
>> ie)
>> ACS master -> develop in git-flow
>> ACS stable -> master in git-flow
>>
>>
>> ~Rajani
>>
>>
>>
>> On 06-Aug-2014, at 10:56 am, Daan Hoogland <da...@gmail.com>
>>wrote:
>>
>>> Hello devs and especially committters,
>>>
>>> I see some -1s coming by, days after the vote was closed. That is
>>> disturbing as it means we accepted a proposal that will not be
>>> supported by the community. So let me try to find that support in
>>> hindsight;
>>>
>>> The argument of Animesh that we are shifting the burden from one
>>> branch to another is real and present danger. I share his concern. It
>>> is not the only feature of this proposal and in it self does not
>>> warrant a -1. It does not worsen the situation at hand or add to our
>>> workload in any way. If there is no advantage to you and no
>>> disadvantage either then why -1 something that others do find useful?
>>> This is 'kind of' a rhetorical question. It is a real concern, however
>>> though not the biggest at this moment.
>>>
>>> branching is recommended but as people are rightfully wondering
>>> "should I make a branch for a single line fix". I would, probably but
>>> maybe not always. That doesn't mean you must. In case you are making a
>>> fix on a release then yes you do. It is how the git-flow workflow
>>> goes.
>>>
>>> Committers can merge and commit where ever they feel the need. That
>>> doesn't exempt them from thinking if it is a good idea. It doesn't now
>>> and it won't in the future. Doing what your boss tells you to do can
>>> be a crime!
>>>
>>> Reverting something should only be done when the code that is a
>>> culprit has been identified. Reverting a big change or even a bunch of
>>> changes is a cowards way out. We shouldn't do it now or using gitflow.
>>> It is not really related to git flow or its use. So we shouldn't
>>> penalize developers that didn't cause a problem or ones that did. We
>>> should help them help us make a better system.
>>>
>>> The question of why this process isn't implemented on master is valid.
>>> It could. It isn't however. It is a choice the authors of gitflow
>>> made. I think it is not really the time anymore to be nitpicking about
>>> this. Unless we find a very valid reason to alter the accepted
>>> proposal we should all try and implement it as good as possible. I
>>> have been RM for 4.4.0 and one thing I don't want anymore is people
>>> share a 4.4-forward to cherry-pick commits from. It caused me a lot of
>>> headaches.
>>>
>>> The release is what drives the merges back to master according to
>>> git-flow. We can decide that we define a number of prerelease dates at
>>> which we merge as well. We don't have to do it at that date but can
>>> decide to do that the next day or week as well. This would kind of
>>> resemble Alena's #1 (as opposed to the more pure gitflow #2). An
>>> argument for #2 is that I don't think every customer greps the rpms
>>> for some release. I know our operators at Schuberg Philis investigate
>>> the code and check it out from git. They like to compare release and
>>> look at the latest easily. just checking out master would be very
>>> convenient for them. Of course they can check out a branch as well.
>>> But I doubt if they know exactly what to checkout then. I usually see
>>> them just look at the latest for a branch.
>>>
>>> All in all, I am very skeptic on whether this will work as planned. It
>>> is us who need to work neatly and only if we do that we can help
>>> ourselves with improving our process. I do feel that the present way
>>> of working, mainly the use forward branches but in general the lack of
>>> using branches to test individual changes, is hindering us in doing
>>> releases. The proposal at hand is very good but can only work if
>>> supported by the people that need to work with it. It doesn't do our
>>> release process for us. We still need to do it and not just program
>>> some code and check it in. That will never work in any process. Your
>>> code is not done until somebody somewhere finds it worth running it in
>>> a production environment. So let's keep discussing and educating each
>>> other.
>>>
>>> done ranting, feel free to react or contact me in person
>>> Daan
>>>
>>>
>>> On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <da...@gnsa.us> wrote:
>>>> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <te...@gmail.com>
>>>>wrote:
>>>>
>>>>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle
>>>>><Pr...@citrix.com>
>>>>> wrote:
>>>>>
>>>>>> I fail to understand how will this model help us with the
>>>>>>maintenance
>>>>>> releases?
>>>>>>
>>>>>>
>>>>> That's what gitflow support branches is for.
>>>>> I find this quite descriptive:
>>>>>
>>>>> 
>>>>>https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06
>>>>>CuKT0J
>>>>>
>>>>>
>>>>>
>>>>>> For CloudStack we also keep working on prior releases and ship out
>>>>>> maintenance releases.
>>>>>> I suppose we will be cutting the maintenance releases from the
>>>>>>release
>>>>>> branches? So we will have to keep around the release branches for
>>>>>>that
>>>>>> purpose.
>>>>>>
>>>>>>
>>>>> I've asked earlier, but what is the policy on old releases? How long
>>>>>do we
>>>>> support them?
>>>>>
>>>>>
>>>> Today (e.g. subject to change) we claim to support as a community the
>>>>two
>>>> most recent feature releases. (for instance, we just stopped support
>>>>the
>>>> 4.2.x line with the release of 4.4.0, and currently support 4.3.x and
>>>> 4.4.x) We support those feature releases with bug fix releases that
>>>>contain
>>>> no additional functionality.
>>>>
>>>> --David
>>>
>>>
>>>
>>> --
>>> Daan
>>
>
>
>
>-- 
>Daan

Re: [VOTE] git workflow

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

Exactly Rajani, and other solutions are possible. The issue is not how
branches are called ;)

On Wed, Aug 6, 2014 at 8:29 AM, Rajani Karuturi
<Ra...@citrix.com> wrote:
> I am just wondering if the shift to a new develop branch is causing the problems. Its a simple branch shift and should be no different from the current master.
>
> may be we should leave the master as is and create a ‘stable' branch which would act like master in git-flow ?
>
> ie)
> ACS master -> develop in git-flow
> ACS stable -> master in git-flow
>
>
> ~Rajani
>
>
>
> On 06-Aug-2014, at 10:56 am, Daan Hoogland <da...@gmail.com> wrote:
>
>> Hello devs and especially committters,
>>
>> I see some -1s coming by, days after the vote was closed. That is
>> disturbing as it means we accepted a proposal that will not be
>> supported by the community. So let me try to find that support in
>> hindsight;
>>
>> The argument of Animesh that we are shifting the burden from one
>> branch to another is real and present danger. I share his concern. It
>> is not the only feature of this proposal and in it self does not
>> warrant a -1. It does not worsen the situation at hand or add to our
>> workload in any way. If there is no advantage to you and no
>> disadvantage either then why -1 something that others do find useful?
>> This is 'kind of' a rhetorical question. It is a real concern, however
>> though not the biggest at this moment.
>>
>> branching is recommended but as people are rightfully wondering
>> "should I make a branch for a single line fix". I would, probably but
>> maybe not always. That doesn't mean you must. In case you are making a
>> fix on a release then yes you do. It is how the git-flow workflow
>> goes.
>>
>> Committers can merge and commit where ever they feel the need. That
>> doesn't exempt them from thinking if it is a good idea. It doesn't now
>> and it won't in the future. Doing what your boss tells you to do can
>> be a crime!
>>
>> Reverting something should only be done when the code that is a
>> culprit has been identified. Reverting a big change or even a bunch of
>> changes is a cowards way out. We shouldn't do it now or using gitflow.
>> It is not really related to git flow or its use. So we shouldn't
>> penalize developers that didn't cause a problem or ones that did. We
>> should help them help us make a better system.
>>
>> The question of why this process isn't implemented on master is valid.
>> It could. It isn't however. It is a choice the authors of gitflow
>> made. I think it is not really the time anymore to be nitpicking about
>> this. Unless we find a very valid reason to alter the accepted
>> proposal we should all try and implement it as good as possible. I
>> have been RM for 4.4.0 and one thing I don't want anymore is people
>> share a 4.4-forward to cherry-pick commits from. It caused me a lot of
>> headaches.
>>
>> The release is what drives the merges back to master according to
>> git-flow. We can decide that we define a number of prerelease dates at
>> which we merge as well. We don't have to do it at that date but can
>> decide to do that the next day or week as well. This would kind of
>> resemble Alena's #1 (as opposed to the more pure gitflow #2). An
>> argument for #2 is that I don't think every customer greps the rpms
>> for some release. I know our operators at Schuberg Philis investigate
>> the code and check it out from git. They like to compare release and
>> look at the latest easily. just checking out master would be very
>> convenient for them. Of course they can check out a branch as well.
>> But I doubt if they know exactly what to checkout then. I usually see
>> them just look at the latest for a branch.
>>
>> All in all, I am very skeptic on whether this will work as planned. It
>> is us who need to work neatly and only if we do that we can help
>> ourselves with improving our process. I do feel that the present way
>> of working, mainly the use forward branches but in general the lack of
>> using branches to test individual changes, is hindering us in doing
>> releases. The proposal at hand is very good but can only work if
>> supported by the people that need to work with it. It doesn't do our
>> release process for us. We still need to do it and not just program
>> some code and check it in. That will never work in any process. Your
>> code is not done until somebody somewhere finds it worth running it in
>> a production environment. So let's keep discussing and educating each
>> other.
>>
>> done ranting, feel free to react or contact me in person
>> Daan
>>
>>
>> On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <da...@gnsa.us> wrote:
>>> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <te...@gmail.com> wrote:
>>>
>>>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle <Pr...@citrix.com>
>>>> wrote:
>>>>
>>>>> I fail to understand how will this model help us with the maintenance
>>>>> releases?
>>>>>
>>>>>
>>>> That's what gitflow support branches is for.
>>>> I find this quite descriptive:
>>>>
>>>> https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J
>>>>
>>>>
>>>>
>>>>> For CloudStack we also keep working on prior releases and ship out
>>>>> maintenance releases.
>>>>> I suppose we will be cutting the maintenance releases from the release
>>>>> branches? So we will have to keep around the release branches for that
>>>>> purpose.
>>>>>
>>>>>
>>>> I've asked earlier, but what is the policy on old releases? How long do we
>>>> support them?
>>>>
>>>>
>>> Today (e.g. subject to change) we claim to support as a community the two
>>> most recent feature releases. (for instance, we just stopped support the
>>> 4.2.x line with the release of 4.4.0, and currently support 4.3.x and
>>> 4.4.x) We support those feature releases with bug fix releases that contain
>>> no additional functionality.
>>>
>>> --David
>>
>>
>>
>> --
>> Daan
>



-- 
Daan

Re: [VOTE] git workflow

[Leo Simons <LS...@schubergphilis.com>]

Good morning,

I have some difficulty believing having to type 'git checkout develop' is enough reason for an apache committer to veto a change like this, especially after the extensive discussions we had and all the docs we wrote.

I think people are seeing bigger problems or haven't quite understood the intended changes or the reason for them. If we can address that, I imagine we'll eventually find the consensus we need...

Cheers,

Leo

Sent from my iPhone

> On 06 Aug 2014, at 08:29, "Rajani Karuturi" <Ra...@citrix.com> wrote:
> 
> I am just wondering if the shift to a new develop branch is causing the problems. Its a simple branch shift and should be no different from the current master.
> 
> may be we should leave the master as is and create a ‘stable' branch which would act like master in git-flow ?
> 
> ie) 
> ACS master -> develop in git-flow
> ACS stable -> master in git-flow 
> 
> 
> ~Rajani
> 
> 
> 
>> On 06-Aug-2014, at 10:56 am, Daan Hoogland <da...@gmail.com> wrote:
>> 
>> Hello devs and especially committters,
>> 
>> I see some -1s coming by, days after the vote was closed. That is
>> disturbing as it means we accepted a proposal that will not be
>> supported by the community. So let me try to find that support in
>> hindsight;
>> 
>> The argument of Animesh that we are shifting the burden from one
>> branch to another is real and present danger. I share his concern. It
>> is not the only feature of this proposal and in it self does not
>> warrant a -1. It does not worsen the situation at hand or add to our
>> workload in any way. If there is no advantage to you and no
>> disadvantage either then why -1 something that others do find useful?
>> This is 'kind of' a rhetorical question. It is a real concern, however
>> though not the biggest at this moment.
>> 
>> branching is recommended but as people are rightfully wondering
>> "should I make a branch for a single line fix". I would, probably but
>> maybe not always. That doesn't mean you must. In case you are making a
>> fix on a release then yes you do. It is how the git-flow workflow
>> goes.
>> 
>> Committers can merge and commit where ever they feel the need. That
>> doesn't exempt them from thinking if it is a good idea. It doesn't now
>> and it won't in the future. Doing what your boss tells you to do can
>> be a crime!
>> 
>> Reverting something should only be done when the code that is a
>> culprit has been identified. Reverting a big change or even a bunch of
>> changes is a cowards way out. We shouldn't do it now or using gitflow.
>> It is not really related to git flow or its use. So we shouldn't
>> penalize developers that didn't cause a problem or ones that did. We
>> should help them help us make a better system.
>> 
>> The question of why this process isn't implemented on master is valid.
>> It could. It isn't however. It is a choice the authors of gitflow
>> made. I think it is not really the time anymore to be nitpicking about
>> this. Unless we find a very valid reason to alter the accepted
>> proposal we should all try and implement it as good as possible. I
>> have been RM for 4.4.0 and one thing I don't want anymore is people
>> share a 4.4-forward to cherry-pick commits from. It caused me a lot of
>> headaches.
>> 
>> The release is what drives the merges back to master according to
>> git-flow. We can decide that we define a number of prerelease dates at
>> which we merge as well. We don't have to do it at that date but can
>> decide to do that the next day or week as well. This would kind of
>> resemble Alena's #1 (as opposed to the more pure gitflow #2). An
>> argument for #2 is that I don't think every customer greps the rpms
>> for some release. I know our operators at Schuberg Philis investigate
>> the code and check it out from git. They like to compare release and
>> look at the latest easily. just checking out master would be very
>> convenient for them. Of course they can check out a branch as well.
>> But I doubt if they know exactly what to checkout then. I usually see
>> them just look at the latest for a branch.
>> 
>> All in all, I am very skeptic on whether this will work as planned. It
>> is us who need to work neatly and only if we do that we can help
>> ourselves with improving our process. I do feel that the present way
>> of working, mainly the use forward branches but in general the lack of
>> using branches to test individual changes, is hindering us in doing
>> releases. The proposal at hand is very good but can only work if
>> supported by the people that need to work with it. It doesn't do our
>> release process for us. We still need to do it and not just program
>> some code and check it in. That will never work in any process. Your
>> code is not done until somebody somewhere finds it worth running it in
>> a production environment. So let's keep discussing and educating each
>> other.
>> 
>> done ranting, feel free to react or contact me in person
>> Daan
>> 
>> 
>>> On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <da...@gnsa.us> wrote:
>>>> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <te...@gmail.com> wrote:
>>>> 
>>>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle <Pr...@citrix.com>
>>>> wrote:
>>>> 
>>>>> I fail to understand how will this model help us with the maintenance
>>>>> releases?
>>>> That's what gitflow support branches is for.
>>>> I find this quite descriptive:
>>>> 
>>>> https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J
>>>> 
>>>> 
>>>> 
>>>>> For CloudStack we also keep working on prior releases and ship out
>>>>> maintenance releases.
>>>>> I suppose we will be cutting the maintenance releases from the release
>>>>> branches? So we will have to keep around the release branches for that
>>>>> purpose.
>>>> I've asked earlier, but what is the policy on old releases? How long do we
>>>> support them?
>>> Today (e.g. subject to change) we claim to support as a community the two
>>> most recent feature releases. (for instance, we just stopped support the
>>> 4.2.x line with the release of 4.4.0, and currently support 4.3.x and
>>> 4.4.x) We support those feature releases with bug fix releases that contain
>>> no additional functionality.
>>> 
>>> --David
>> 
>> 
>> 
>> -- 
>> Daan
> 

Re: [VOTE] git workflow

[Rajani Karuturi <Ra...@citrix.com>]

I am just wondering if the shift to a new develop branch is causing the problems. Its a simple branch shift and should be no different from the current master.

may be we should leave the master as is and create a ‘stable' branch which would act like master in git-flow ?

ie) 
ACS master -> develop in git-flow
ACS stable -> master in git-flow 


~Rajani



On 06-Aug-2014, at 10:56 am, Daan Hoogland <da...@gmail.com> wrote:

> Hello devs and especially committters,
> 
> I see some -1s coming by, days after the vote was closed. That is
> disturbing as it means we accepted a proposal that will not be
> supported by the community. So let me try to find that support in
> hindsight;
> 
> The argument of Animesh that we are shifting the burden from one
> branch to another is real and present danger. I share his concern. It
> is not the only feature of this proposal and in it self does not
> warrant a -1. It does not worsen the situation at hand or add to our
> workload in any way. If there is no advantage to you and no
> disadvantage either then why -1 something that others do find useful?
> This is 'kind of' a rhetorical question. It is a real concern, however
> though not the biggest at this moment.
> 
> branching is recommended but as people are rightfully wondering
> "should I make a branch for a single line fix". I would, probably but
> maybe not always. That doesn't mean you must. In case you are making a
> fix on a release then yes you do. It is how the git-flow workflow
> goes.
> 
> Committers can merge and commit where ever they feel the need. That
> doesn't exempt them from thinking if it is a good idea. It doesn't now
> and it won't in the future. Doing what your boss tells you to do can
> be a crime!
> 
> Reverting something should only be done when the code that is a
> culprit has been identified. Reverting a big change or even a bunch of
> changes is a cowards way out. We shouldn't do it now or using gitflow.
> It is not really related to git flow or its use. So we shouldn't
> penalize developers that didn't cause a problem or ones that did. We
> should help them help us make a better system.
> 
> The question of why this process isn't implemented on master is valid.
> It could. It isn't however. It is a choice the authors of gitflow
> made. I think it is not really the time anymore to be nitpicking about
> this. Unless we find a very valid reason to alter the accepted
> proposal we should all try and implement it as good as possible. I
> have been RM for 4.4.0 and one thing I don't want anymore is people
> share a 4.4-forward to cherry-pick commits from. It caused me a lot of
> headaches.
> 
> The release is what drives the merges back to master according to
> git-flow. We can decide that we define a number of prerelease dates at
> which we merge as well. We don't have to do it at that date but can
> decide to do that the next day or week as well. This would kind of
> resemble Alena's #1 (as opposed to the more pure gitflow #2). An
> argument for #2 is that I don't think every customer greps the rpms
> for some release. I know our operators at Schuberg Philis investigate
> the code and check it out from git. They like to compare release and
> look at the latest easily. just checking out master would be very
> convenient for them. Of course they can check out a branch as well.
> But I doubt if they know exactly what to checkout then. I usually see
> them just look at the latest for a branch.
> 
> All in all, I am very skeptic on whether this will work as planned. It
> is us who need to work neatly and only if we do that we can help
> ourselves with improving our process. I do feel that the present way
> of working, mainly the use forward branches but in general the lack of
> using branches to test individual changes, is hindering us in doing
> releases. The proposal at hand is very good but can only work if
> supported by the people that need to work with it. It doesn't do our
> release process for us. We still need to do it and not just program
> some code and check it in. That will never work in any process. Your
> code is not done until somebody somewhere finds it worth running it in
> a production environment. So let's keep discussing and educating each
> other.
> 
> done ranting, feel free to react or contact me in person
> Daan
> 
> 
> On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <da...@gnsa.us> wrote:
>> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <te...@gmail.com> wrote:
>> 
>>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle <Pr...@citrix.com>
>>> wrote:
>>> 
>>>> I fail to understand how will this model help us with the maintenance
>>>> releases?
>>>> 
>>>> 
>>> That's what gitflow support branches is for.
>>> I find this quite descriptive:
>>> 
>>> https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J
>>> 
>>> 
>>> 
>>>> For CloudStack we also keep working on prior releases and ship out
>>>> maintenance releases.
>>>> I suppose we will be cutting the maintenance releases from the release
>>>> branches? So we will have to keep around the release branches for that
>>>> purpose.
>>>> 
>>>> 
>>> I've asked earlier, but what is the policy on old releases? How long do we
>>> support them?
>>> 
>>> 
>> Today (e.g. subject to change) we claim to support as a community the two
>> most recent feature releases. (for instance, we just stopped support the
>> 4.2.x line with the release of 4.4.0, and currently support 4.3.x and
>> 4.4.x) We support those feature releases with bug fix releases that contain
>> no additional functionality.
>> 
>> --David
> 
> 
> 
> -- 
> Daan

Re: [VOTE] git workflow

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

Hello devs and especially committters,

I see some -1s coming by, days after the vote was closed. That is
disturbing as it means we accepted a proposal that will not be
supported by the community. So let me try to find that support in
hindsight;

The argument of Animesh that we are shifting the burden from one
branch to another is real and present danger. I share his concern. It
is not the only feature of this proposal and in it self does not
warrant a -1. It does not worsen the situation at hand or add to our
workload in any way. If there is no advantage to you and no
disadvantage either then why -1 something that others do find useful?
This is 'kind of' a rhetorical question. It is a real concern, however
though not the biggest at this moment.

branching is recommended but as people are rightfully wondering
"should I make a branch for a single line fix". I would, probably but
maybe not always. That doesn't mean you must. In case you are making a
fix on a release then yes you do. It is how the git-flow workflow
goes.

Committers can merge and commit where ever they feel the need. That
doesn't exempt them from thinking if it is a good idea. It doesn't now
and it won't in the future. Doing what your boss tells you to do can
be a crime!

Reverting something should only be done when the code that is a
culprit has been identified. Reverting a big change or even a bunch of
changes is a cowards way out. We shouldn't do it now or using gitflow.
It is not really related to git flow or its use. So we shouldn't
penalize developers that didn't cause a problem or ones that did. We
should help them help us make a better system.

The question of why this process isn't implemented on master is valid.
It could. It isn't however. It is a choice the authors of gitflow
made. I think it is not really the time anymore to be nitpicking about
this. Unless we find a very valid reason to alter the accepted
proposal we should all try and implement it as good as possible. I
have been RM for 4.4.0 and one thing I don't want anymore is people
share a 4.4-forward to cherry-pick commits from. It caused me a lot of
headaches.

The release is what drives the merges back to master according to
git-flow. We can decide that we define a number of prerelease dates at
which we merge as well. We don't have to do it at that date but can
decide to do that the next day or week as well. This would kind of
resemble Alena's #1 (as opposed to the more pure gitflow #2). An
argument for #2 is that I don't think every customer greps the rpms
for some release. I know our operators at Schuberg Philis investigate
the code and check it out from git. They like to compare release and
look at the latest easily. just checking out master would be very
convenient for them. Of course they can check out a branch as well.
But I doubt if they know exactly what to checkout then. I usually see
them just look at the latest for a branch.

All in all, I am very skeptic on whether this will work as planned. It
is us who need to work neatly and only if we do that we can help
ourselves with improving our process. I do feel that the present way
of working, mainly the use forward branches but in general the lack of
using branches to test individual changes, is hindering us in doing
releases. The proposal at hand is very good but can only work if
supported by the people that need to work with it. It doesn't do our
release process for us. We still need to do it and not just program
some code and check it in. That will never work in any process. Your
code is not done until somebody somewhere finds it worth running it in
a production environment. So let's keep discussing and educating each
other.

done ranting, feel free to react or contact me in person
Daan


On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <da...@gnsa.us> wrote:
> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <te...@gmail.com> wrote:
>
>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle <Pr...@citrix.com>
>> wrote:
>>
>> > I fail to understand how will this model help us with the maintenance
>> > releases?
>> >
>> >
>> That's what gitflow support branches is for.
>> I find this quite descriptive:
>>
>> https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J
>>
>>
>>
>> > For CloudStack we also keep working on prior releases and ship out
>> > maintenance releases.
>> > I suppose we will be cutting the maintenance releases from the release
>> > branches? So we will have to keep around the release branches for that
>> > purpose.
>> >
>> >
>> I've asked earlier, but what is the policy on old releases? How long do we
>> support them?
>>
>>
> Today (e.g. subject to change) we claim to support as a community the two
> most recent feature releases. (for instance, we just stopped support the
> 4.2.x line with the release of 4.4.0, and currently support 4.3.x and
> 4.4.x) We support those feature releases with bug fix releases that contain
> no additional functionality.
>
> --David



-- 
Daan

Re: [VOTE] git workflow

[David Nalley <da...@gnsa.us>]

On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <te...@gmail.com> wrote:

> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle <Pr...@citrix.com>
> wrote:
>
> > I fail to understand how will this model help us with the maintenance
> > releases?
> >
> >
> That's what gitflow support branches is for.
> I find this quite descriptive:
>
> https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J
>
>
>
> > For CloudStack we also keep working on prior releases and ship out
> > maintenance releases.
> > I suppose we will be cutting the maintenance releases from the release
> > branches? So we will have to keep around the release branches for that
> > purpose.
> >
> >
> I've asked earlier, but what is the policy on old releases? How long do we
> support them?
>
>
Today (e.g. subject to change) we claim to support as a community the two
most recent feature releases. (for instance, we just stopped support the
4.2.x line with the release of 4.4.0, and currently support 4.3.x and
4.4.x) We support those feature releases with bug fix releases that contain
no additional functionality.

--David

Re: [VOTE] git workflow

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

On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle <Pr...@citrix.com>
wrote:

> I fail to understand how will this model help us with the maintenance
> releases?
>
>
That's what gitflow support branches is for.
I find this quite descriptive:
https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J



> For CloudStack we also keep working on prior releases and ship out
> maintenance releases.
> I suppose we will be cutting the maintenance releases from the release
> branches? So we will have to keep around the release branches for that
> purpose.
>
>
I've asked earlier, but what is the policy on old releases? How long do we
support them?

-- 
Erik

Re: [VOTE] git workflow

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

Agree with Prachi and Alena here. As a developer, I am more towards having
"developer" branch as a staging area to periodically merge into master
when CI pass on it, this is the simplest way to make master branch stable,
if that is the original intention of this proposal.

Also, before we figure out all the details of the proposal, we should not
start implementing and adopting the process.

-min

On 8/5/14 3:55 PM, "Prachi Damle" <Pr...@citrix.com> wrote:

>I fail to understand how will this model help us with the maintenance
>releases? 
>
>For CloudStack we also keep working on prior releases and ship out
>maintenance releases.
>I suppose we will be cutting the maintenance releases from the release
>branches? So we will have to keep around the release branches for that
>purpose.
>
>In that case isn't master branch a redundant copy of the release branches?
>
>I think what we really need is having a staging branch where CI runs and
>pushes code to master only if CI passes in turn keeping master stable.
>I think 'develop' branch should serve such use.
>
>
>Thanks,
>Prachi
>
>-----Original Message-----
>From: Sebastien Goasguen [mailto:runseb@gmail.com]
>Sent: Tuesday, August 05, 2014 2:56 PM
>To: dev@cloudstack.apache.org
>Subject: Re: [VOTE] git workflow
>
>
>On Aug 5, 2014, at 2:33 PM, Jessica Wang <Je...@citrix.com> wrote:
>
>> Exactly. This just shifts pain from one branch to another.
>> I don't see any gains from this, either.
>> I vote "-1".
>> 
>
>It is much more than shifting pains, the wiki page is not discussion the
>workflow quite extensively, with several pointers that we should all take
>the time to view/read:
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git
>
>
>> Jessica
>> 
>> 
>> -----Original Message-----
>> From: Min Chen [mailto:min.chen@citrix.com]
>> Sent: Tuesday, August 05, 2014 11:27 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] git workflow
>> 
>> Agree with Animesh. Didn't see any gains from this, we just shift pain
>> from one branch to another, so vote -1.
>> 
>> -min
>> 
>> On 8/2/14 9:50 PM, "Animesh Chaturvedi"
>> <an...@citrix.com>
>> wrote:
>> 
>>> +0
>>> 
>>> While this protects master with only commits which are merges from
>>> release branch and keeps it clean but the issues that we have shift
>>> to develop branch.
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>>>> Sent: Thursday, July 31, 2014 3:28 AM
>>>> To: dev
>>>> Subject: [VOTE] git workflow
>>>> 
>>>> Hi All,
>>>> 
>>>> We had long discussions on the git flow.
>>>> I tried to capture the summary of it @
>>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>>> This is updated on wiki @
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>>>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>>>> 
>>>> Can you share your opinion on the proposal?
>>>> 
>>>> [ ] +1  approve
>>>> [ ] +0  no opinion
>>>> [ ] -1  disapprove (and reason why)
>>>> 
>>>> 
>>>> Thanks,
>>>> ~Rajani
>>>> 
>>>> 
>>> 
>> 
>

RE: [VOTE] git workflow

[Prachi Damle <Pr...@citrix.com>]

I fail to understand how will this model help us with the maintenance releases? 

For CloudStack we also keep working on prior releases and ship out maintenance releases.
I suppose we will be cutting the maintenance releases from the release branches? So we will have to keep around the release branches for that purpose.

In that case isn't master branch a redundant copy of the release branches?

I think what we really need is having a staging branch where CI runs and pushes code to master only if CI passes in turn keeping master stable. 
I think 'develop' branch should serve such use.


Thanks,
Prachi

-----Original Message-----
From: Sebastien Goasguen [mailto:runseb@gmail.com] 
Sent: Tuesday, August 05, 2014 2:56 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow


On Aug 5, 2014, at 2:33 PM, Jessica Wang <Je...@citrix.com> wrote:

> Exactly. This just shifts pain from one branch to another. 
> I don't see any gains from this, either.
> I vote "-1".
> 

It is much more than shifting pains, the wiki page is not discussion the workflow quite extensively, with several pointers that we should all take the time to view/read:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git


> Jessica
> 
> 
> -----Original Message-----
> From: Min Chen [mailto:min.chen@citrix.com]
> Sent: Tuesday, August 05, 2014 11:27 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] git workflow
> 
> Agree with Animesh. Didn't see any gains from this, we just shift pain 
> from one branch to another, so vote -1.
> 
> -min
> 
> On 8/2/14 9:50 PM, "Animesh Chaturvedi" 
> <an...@citrix.com>
> wrote:
> 
>> +0
>> 
>> While this protects master with only commits which are merges from 
>> release branch and keeps it clean but the issues that we have shift 
>> to develop branch.
>> 
>> 
>>> -----Original Message-----
>>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>>> Sent: Thursday, July 31, 2014 3:28 AM
>>> To: dev
>>> Subject: [VOTE] git workflow
>>> 
>>> Hi All,
>>> 
>>> We had long discussions on the git flow.
>>> I tried to capture the summary of it @ 
>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>> This is updated on wiki @
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>>> 
>>> Can you share your opinion on the proposal?
>>> 
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>> 
>>> 
>>> Thanks,
>>> ~Rajani
>>> 
>>> 
>> 
> 

Re: [VOTE] git workflow

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

On Aug 5, 2014, at 2:33 PM, Jessica Wang <Je...@citrix.com> wrote:

> Exactly. This just shifts pain from one branch to another. 
> I don't see any gains from this, either.
> I vote "-1".
> 

It is much more than shifting pains, the wiki page is not discussion the workflow quite extensively, with several pointers that we should all take the time to view/read:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git


> Jessica
> 
> 
> -----Original Message-----
> From: Min Chen [mailto:min.chen@citrix.com] 
> Sent: Tuesday, August 05, 2014 11:27 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] git workflow
> 
> Agree with Animesh. Didn't see any gains from this, we just shift pain
> from one branch to another, so vote -1.
> 
> -min
> 
> On 8/2/14 9:50 PM, "Animesh Chaturvedi" <an...@citrix.com>
> wrote:
> 
>> +0
>> 
>> While this protects master with only commits which are merges from
>> release branch and keeps it clean but the issues that we have shift to
>> develop branch. 
>> 
>> 
>>> -----Original Message-----
>>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>>> Sent: Thursday, July 31, 2014 3:28 AM
>>> To: dev
>>> Subject: [VOTE] git workflow
>>> 
>>> Hi All,
>>> 
>>> We had long discussions on the git flow.
>>> I tried to capture the summary of it @
>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>> This is updated on wiki @
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>>> 
>>> Can you share your opinion on the proposal?
>>> 
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>> 
>>> 
>>> Thanks,
>>> ~Rajani
>>> 
>>> 
>> 
> 

RE: [VOTE] git workflow

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

Exactly. This just shifts pain from one branch to another. 
I don't see any gains from this, either.
I vote "-1".

Jessica


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

Agree with Animesh. Didn't see any gains from this, we just shift pain
from one branch to another, so vote -1.

-min

On 8/2/14 9:50 PM, "Animesh Chaturvedi" <an...@citrix.com>
wrote:

>+0
>
>While this protects master with only commits which are merges from
>release branch and keeps it clean but the issues that we have shift to
>develop branch. 
>
>
>> -----Original Message-----
>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>> Sent: Thursday, July 31, 2014 3:28 AM
>> To: dev
>> Subject: [VOTE] git workflow
>> 
>> Hi All,
>> 
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @
>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>> 
>> Can you share your opinion on the proposal?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> 
>> Thanks,
>> ~Rajani
>> 
>> 
>

Re: [VOTE] git workflow

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

Agree with Animesh. Didn't see any gains from this, we just shift pain
from one branch to another, so vote -1.

-min

On 8/2/14 9:50 PM, "Animesh Chaturvedi" <an...@citrix.com>
wrote:

>+0
>
>While this protects master with only commits which are merges from
>release branch and keeps it clean but the issues that we have shift to
>develop branch. 
>
>
>> -----Original Message-----
>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>> Sent: Thursday, July 31, 2014 3:28 AM
>> To: dev
>> Subject: [VOTE] git workflow
>> 
>> Hi All,
>> 
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @
>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>> 
>> Can you share your opinion on the proposal?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> 
>> Thanks,
>> ~Rajani
>> 
>> 
>

RE: [VOTE] git workflow

[Animesh Chaturvedi <an...@citrix.com>]

+0

While this protects master with only commits which are merges from release branch and keeps it clean but the issues that we have shift to develop branch. 


> -----Original Message-----
> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
> Sent: Thursday, July 31, 2014 3:28 AM
> To: dev
> Subject: [VOTE] git workflow
> 
> Hi All,
> 
> We had long discussions on the git flow.
> I tried to capture the summary of it @
> http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
> ProposedGitflowbasedCheck-inProcess and is up for a vote:
> 
> Can you share your opinion on the proposal?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> 
> Thanks,
> ~Rajani
> 
> 

Re: [VOTE] git workflow

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

+1

PL


On Thu, Jul 31, 2014 at 7:40 AM, Rajani Karuturi <Rajani.Karuturi@citrix.com
> wrote:

> Hi Hugo,
>
> Its mainly to get an opinion on the proposal.
> I am expecting all the active committers to take a look at it and raise
> any concerns they have.
>
> If we don’t get any -1’s or edits, we should start on it.
> Post voting, if its approved, we should do the required git branch changes
> as suggested in the proposal and all the new checkins are expected to
> follow the new commit flow for 4.5+.
>
> if its not approved, we are either happy with the existing flow or we will
> have some good suggestions with which we may need to start a vote again.
>
>
> ~Rajani
>
>
>
> On 31-Jul-2014, at 4:13 pm, Hugo Trippaers <hu...@trippaers.nl> wrote:
>
> > Rajani,
> >
> > To make it clear for everyone. This is the vote to adopt this new way of
> working right? Or is it just to get an opinion on the proposal?
> >
> > If it is indeed the vote to adopt this way of working it means that all
> committers will change how we interact with the branches in the CloudStack
> git.
> >
> > It’s is a good thing in my book, but we need to be clear what the
> expected result is when this vote has concluded in 72 hours.
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > On 31 jul. 2014, at 12:28, Rajani Karuturi <Ra...@citrix.com>
> wrote:
> >
> >> Hi All,
> >>
> >> We had long discussions on the git flow.
> >> I tried to capture the summary of it @
> http://markmail.org/message/j5z7dxjcqxfkfhpj
> >> This is updated on wiki @
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
> and is up for a vote:
> >>
> >> Can you share your opinion on the proposal?
> >>
> >> [ ] +1  approve
> >> [ ] +0  no opinion
> >> [ ] -1  disapprove (and reason why)
> >>
> >>
> >> Thanks,
> >> ~Rajani
> >>
> >>
> >>
> >
>
>

Re: [VOTE] git workflow

[Rajani Karuturi <Ra...@citrix.com>]

Hi Hugo,

Its mainly to get an opinion on the proposal.
I am expecting all the active committers to take a look at it and raise any concerns they have.

If we don’t get any -1’s or edits, we should start on it.
Post voting, if its approved, we should do the required git branch changes as suggested in the proposal and all the new checkins are expected to follow the new commit flow for 4.5+.

if its not approved, we are either happy with the existing flow or we will have some good suggestions with which we may need to start a vote again.


~Rajani



On 31-Jul-2014, at 4:13 pm, Hugo Trippaers <hu...@trippaers.nl> wrote:

> Rajani,
> 
> To make it clear for everyone. This is the vote to adopt this new way of working right? Or is it just to get an opinion on the proposal?
> 
> If it is indeed the vote to adopt this way of working it means that all committers will change how we interact with the branches in the CloudStack git.  
> 
> It’s is a good thing in my book, but we need to be clear what the expected result is when this vote has concluded in 72 hours. 
> 
> Cheers,
> 
> Hugo
> 
> 
> On 31 jul. 2014, at 12:28, Rajani Karuturi <Ra...@citrix.com> wrote:
> 
>> Hi All,
>> 
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @ http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote:
>> 
>> Can you share your opinion on the proposal?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> 
>> Thanks,
>> ~Rajani
>> 
>> 
>> 
> 

Re: [VOTE] git workflow

[Ian Duffy <ia...@ianduffy.ie>]

+1
On 31 Jul 2014 21:33, "Alena Prokharchyk" <Al...@citrix.com>
wrote:

> +1 on the proposal. But I second Rohit and Sheng Yang - we should agree on
> all the flow points before we adopt it for CloudStack. We can¹t just
> blindly follow http://nvie.com/posts/a-successful-git-branching-model/,
> plus some use cases are not explained there as I¹ve pointed in one of my
> previous emails.
>
> -Alena.
>
> On 7/31/14, 4:19 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>
> >+1
> >
> >Hugo, I think we started this voting thread to get opinion on the
> >proposal. I feel it may need some iteration and community agreement
> >before we adopt it.
> >
> >Suggestions, flames and opinions are welcome.
> >
> >Regards.
> >
> >
> >On 31-Jul-2014, at 12:43 pm, Hugo Trippaers <hu...@trippaers.nl> wrote:
> >
> >> Rajani,
> >>
> >> To make it clear for everyone. This is the vote to adopt this new way
> >>of working right? Or is it just to get an opinion on the proposal?
> >>
> >> If it is indeed the vote to adopt this way of working it means that all
> >>committers will change how we interact with the branches in the
> >>CloudStack git.
> >>
> >> It¹s is a good thing in my book, but we need to be clear what the
> >>expected result is when this vote has concluded in 72 hours.
> >>
> >> Cheers,
> >>
> >> Hugo
> >>
> >>
> >> On 31 jul. 2014, at 12:28, Rajani Karuturi <Ra...@citrix.com>
> >>wrote:
> >>
> >>> Hi All,
> >>>
> >>> We had long discussions on the git flow.
> >>> I tried to capture the summary of it @
> >>>http://markmail.org/message/j5z7dxjcqxfkfhpj
> >>> This is updated on wiki @
> >>>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedG
> >>>itflowbasedCheck-inProcess and is up for a vote:
> >>>
> >>> Can you share your opinion on the proposal?
> >>>
> >>> [ ] +1  approve
> >>> [ ] +0  no opinion
> >>> [ ] -1  disapprove (and reason why)
> >>>
> >>>
> >>> Thanks,
> >>> ~Rajani
> >>>
> >>>
> >>>
> >>
> >
> >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] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Sorry, ignore #2. I’ve read on the model more, and realized that master
branch would reflect the branch that has been released, not the current
release.

So only #1 is yet to be addressed.

-alena.

On 7/31/14, 2:03 PM, "Alena Prokharchyk" <Al...@citrix.com>
wrote:

>Done, updated the wiki page with my comments. Copy/pasting here:
>
>Open items:
>1) Which bugs can be submitted to develop branch directly.
>Document http://nvie.com/posts/a-successful-git-branching-model/ mentions
>that the
>*hotfix branch should be created for the blocker/critical bugs in the
>current production release. What about bugs happenning in the *release(the
>one that hasn't been released yet)/*develop
>branches ? Should we fix them directly in those branches, or should we
>branch out off the *release
>branch, fix the problem, and merge the fix to *release?
>We should decide:
>for which bugs the hot fix branch should be cut, and which fixes can go
>directly to *develop/*release branches. This criteria has to be defined in
>the doc, and be based on the a) bug severity b) number of people who work
>on the bug - if more than one, then we cut the new branch c)
>feedback/review is needed for the bug d) anything else?
>
>2) I don't agree with the model when the person has to merge his
>branch/commit the fix to both develop/master branches. So there are 2
>approaches that can be taken:
>* Currently proposed approach: ask a person always put 2 fixes - one in
>master and one in develop
>* Approach I suggest, and its used in the field a lot: Person commits the
>fixes to *develop branch, and then there is some job doing automatic merge
>from *develop to *master branch after CI on *develop passes
>
>From the past experience, I see that the first (currently proposed)
>approach is less desirable as a) sometimes people forget to push changes
>into master branch, and then the release manager has to run the merge to
>find those missing pieces b) IMPORTANT: it would require to run CI on both
>*develop and *master branch with higher frequency, plus the rollbacks in
>case of failure need to be done both in develop and master branches. I
>would advocate for the following flow:
>
>* submit fixes/merges from release/hotfix branches to *develop branch only
>* Run daily(?) CI on develop branch, and do merge delta to master branch
>only when CI passes
>
>-Alena.
>
>
>
>
>
>
>On 7/31/14, 1:40 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:
>
>>
>>On Jul 31, 2014, at 4:33 PM, Alena Prokharchyk
>><Al...@citrix.com> wrote:
>>
>>> +1 on the proposal. But I second Rohit and Sheng Yang - we should agree
>>>on
>>> all the flow points before we adopt it for CloudStack. We can¹t just
>>> blindly follow http://nvie.com/posts/a-successful-git-branching-model/,
>>> plus some use cases are not explained there as I¹ve pointed in one of
>>>my
>>> previous emails.
>>> 
>>
>>Can you add to the wiki page then ? describe the use case that you have
>>in mind and explain how to address it.
>>
>>If we all collaboratively edit that page we should be able to get to a
>>consensus and have something that addresses all our current concerns.
>>
>>
>>> -Alena.
>>> 
>>> On 7/31/14, 4:19 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>> 
>>>> +1
>>>> 
>>>> Hugo, I think we started this voting thread to get opinion on the
>>>> proposal. I feel it may need some iteration and community agreement
>>>> before we adopt it.
>>>> 
>>>> Suggestions, flames and opinions are welcome.
>>>> 
>>>> Regards.
>>>> 
>>>> 
>>>> On 31-Jul-2014, at 12:43 pm, Hugo Trippaers <hu...@trippaers.nl> wrote:
>>>> 
>>>>> Rajani,
>>>>> 
>>>>> To make it clear for everyone. This is the vote to adopt this new way
>>>>> of working right? Or is it just to get an opinion on the proposal?
>>>>> 
>>>>> If it is indeed the vote to adopt this way of working it means that
>>>>>all
>>>>> committers will change how we interact with the branches in the
>>>>> CloudStack git.
>>>>> 
>>>>> It¹s is a good thing in my book, but we need to be clear what the
>>>>> expected result is when this vote has concluded in 72 hours.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Hugo
>>>>> 
>>>>> 
>>>>> On 31 jul. 2014, at 12:28, Rajani Karuturi
>>>>><Ra...@citrix.com>
>>>>> wrote:
>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> We had long discussions on the git flow.
>>>>>> I tried to capture the summary of it @
>>>>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>>>>> This is updated on wiki @
>>>>>> 
>>>>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-Propos
>>>>>>e
>>>>>>dG
>>>>>> itflowbasedCheck-inProcess and is up for a vote:
>>>>>> 
>>>>>> Can you share your opinion on the proposal?
>>>>>> 
>>>>>> [ ] +1  approve
>>>>>> [ ] +0  no opinion
>>>>>> [ ] -1  disapprove (and reason why)
>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> ~Rajani
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 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] git workflow

[Stephen Turner <St...@citrix.com>]

> From: Sheng Yang [mailto:sheng@yasker.org]
> Work need to be tested, but create one branch for every bug seems over doing. Branch in Git suppose to use with substantial changes.

Actually, I don't agree with you on that point. I think git is unusual among source control systems in that the git mantra is that branching and merging are easy and cheap and so everything goes on a new branch and making new branches becomes part of your daily workflow.

-- 
Stephen Turner

Re: [VOTE] git workflow

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

Hi,

On 01-Aug-2014, at 1:59 am, Sheng Yang <sh...@yasker.org> wrote:

> Work need to be tested, but create one branch for every bug seems over
> doing. Branch in Git suppose to use with substantial changes. I don't think
> anyone would like the idea to have 2 commits for every bug fixes(one merge
> commit and one real fix). And it's not the case in the original model as
> well.

I understand what you’re saying but it’s not the only way to merge;

It’s good to start off in a bug’s own branch, there is no need to simply merge the branch to target/master/develop branch, instead you can do a squash merge (resulting in one commit and linear history) or cherry-pick as applicable.

> Patch can be tested by other ways, e.g. upload patches to test system, or
> introduce e.g. gerrit, which can integrated with Jenkins to run test on
> specific review commit, without commit it to the repo, which I really like
> to recommended to enforce the testing. Simply branching out wouldn't mean
> you would test it.

There is another thread on speeding up validations of your checkins - http://markmail.org/message/w2hqmrfpfrhsife6

For small fixes where developer is sure it does not affect the system (say a change in UI, string fixes, refactorings etc.) he may skip smoke tests but for his a lot of work he may run it often. Automated systems will eventually find the bug but it’s good idea to validate your changes before you push them to master/develop etc.

Regards.

>
> --Sheng

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] git workflow

[Sheng Yang <sh...@yasker.org>]

On Thu, Jul 31, 2014 at 4:28 PM, Rohit Yadav <ro...@shapeblue.com>
wrote:

> Comments in-line;
>
> On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
> > Done, updated the wiki page with my comments. Copy/pasting here:
> >
> > Open items:
> > 1) Which bugs can be submitted to develop branch directly.
> > Document http://nvie.com/posts/a-successful-git-branching-model/
> mentions
> > that the
> > *hotfix branch should be created for the blocker/critical bugs in the
> > current production release. What about bugs happenning in the
> *release(the
> > one that hasn't been released yet)/*develop
> > branches ? Should we fix them directly in those branches, or should we
> > branch out off the *release
> > branch, fix the problem, and merge the fix to *release?
>
> As per nvie;
>
> once cut out release branches should only have bugfixes. So, bugfixes can
> directly land on release branch and then cherry-picked or merge to the
> develop branch.
>
> For bugs on develop branch, the commits can land directly on the develop
> branch or can be worked in a branch checked out from develop and when done
> merged back.
>
> In my opinion, for any case developers should not work on any of the
> branches (master, release, develop) directly but checkout branch and work
> on it and merge back (or cherry-pick or squash merge) to respective branch
> only when their work is complete, with unit tests and validated using unit
> testing and smoke tests (BVT).
>

Work need to be tested, but create one branch for every bug seems over
doing. Branch in Git suppose to use with substantial changes. I don't think
anyone would like the idea to have 2 commits for every bug fixes(one merge
commit and one real fix). And it's not the case in the original model as
well.

Patch can be tested by other ways, e.g. upload patches to test system, or
introduce e.g. gerrit, which can integrated with Jenkins to run test on
specific review commit, without commit it to the repo, which I really like
to recommended to enforce the testing. Simply branching out wouldn't mean
you would test it.

--Sheng


>
> > We should decide:
> > for which bugs the hot fix branch should be cut, and which fixes can go
> > directly to *develop/*release branches. This criteria has to be defined
> in
> > the doc, and be based on the a) bug severity b) number of people who work
> > on the bug - if more than one, then we cut the new branch c)
> > feedback/review is needed for the bug d) anything else?
>
> What you suggest is fine. I think couple of areas which can qualify for
> bugfixes (hotfixes) would be related to security, database changes,
> systemvms, agent, hypervisor, network, storage, anything that could be
> considered a blocker.
>
> I’m not sure but I think adopting nvie could possibly affect our release
> process, I would let PMC and experienced RMs to comment on this issue and
> if they would like any modifications to the release process?
>
> On twitter I asked @nvie if he would have any change in the nvie model, he
> has a short reply:
> https://twitter.com/nvie/status/494870892917563393
>
> 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] git workflow

[Animesh Chaturvedi <an...@citrix.com>]

> -----Original Message-----
> From: Sebastien Goasguen [mailto:runseb@gmail.com]
> Sent: Friday, August 01, 2014 7:42 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] git workflow
> 
> 
> On Aug 1, 2014, at 10:30 AM, Nate Gordon <na...@appcore.com>
> wrote:
> 
> > +1
> >
> > On CI, I think it should run on any branch that wants to maintain quality.
> > So master, develop, releases, hotfixes, and support. It would be
> > awesome if I could elect to have my random other branches run CI as
> > well, but my guess is that we would need more hardware to pull that
> > off. Hopefully I'll have some extra hardware to donate to the cause in
> > the next few months, but need to get everything currently on it moved
> somewhere else first.
> >
> 
> FWIW, a few of us are looking at a TravisCI setup to run the simulator.
> Assuming the tests would run quickly (< 60 minutes on travis hardware),
> we could have tests run on every commit for every branch mirrored on
> github (.I hear some of you say "yeah right."). But imho that would be an
> ideal scenario, as folks own fork could also run the simulator automatically.
> Will see if we get anywhere with this.
> 
[Animesh] that will be awesome
> >
> > On Fri, Aug 1, 2014 at 5:37 AM, Rohit Yadav
> > <ro...@shapeblue.com>
> > wrote:
> >
> >>
> >> On 01-Aug-2014, at 1:40 am, Alena Prokharchyk <
> >> Alena.Prokharchyk@citrix.com> wrote:
> >>
> >>> Thank you, Rohit. Couple more things we have to clarify in the wiki.
> >>> The doc says "Developer should run the BVT on the simulator before
> >>> doing a checkin², but it doesn¹t mention anything about the CI. So
> >>> here are my
> >>> questions:
> >>>
> >>> 1) CI execution
> >>>
> >>> * on which branches we are planning to run the CI
> >>> * with what frequency
> >>
> >> Automated systems will be there for main branches such as develop,
> >> master, release etc.
> >>
> >> The frequency would vary, the best I'm able to get on my local lab is
> >> 50 mins per BVT run (advanced).
> >>
> >> For feature, bug fix, developer's personal branches developers can
> >> setup a CI with Travis, Azure (Edison says free subscription is
> >> available), AWS
> >> (free-tier) etc. at least say once a day run the BVTs on their
> >> laptop/desktop before pushing the code to their remote branch.
> >>
> >>>
> >>> 2) Reverting the fixes breaking the CI - are we planning to do it?
> >>> If so, would it be done automatically after CI run, or developer
> >>> should do it himself?
> >>
> >> I think a human should do it.
> >> In the past we've seen developer revert breaking commit(s) and
> >> reaching out to the author/community about it.
> >>
> >> Regards.
> >>
> >>>
> >>>
> >>> -Alena.
> >>>
> >>> On 7/31/14, 4:28 PM, "Rohit Yadav" <ro...@shapeblue.com>
> wrote:
> >>>
> >>>> Comments in-line;
> >>>>
> >>>> On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk
> >>>> <Al...@citrix.com> wrote:
> >>>>
> >>>>> Done, updated the wiki page with my comments. Copy/pasting here:
> >>>>>
> >>>>> Open items:
> >>>>> 1) Which bugs can be submitted to develop branch directly.
> >>>>> Document http://nvie.com/posts/a-successful-git-branching-model/
> >>>>> mentions
> >>>>> that the
> >>>>> *hotfix branch should be created for the blocker/critical bugs in
> >>>>> the current production release. What about bugs happenning in the
> >>>>> *release(the one that hasn't been released yet)/*develop branches
> >>>>> ? Should we fix them directly in those branches, or should we
> >>>>> branch out off the *release branch, fix the problem, and merge the
> >>>>> fix to *release?
> >>>>
> >>>> As per nvie;
> >>>>
> >>>> once cut out release branches should only have bugfixes. So,
> >>>> bugfixes
> >> can
> >>>> directly land on release branch and then cherry-picked or merge to
> >>>> the develop branch.
> >>>>
> >>>> For bugs on develop branch, the commits can land directly on the
> >>>> develop branch or can be worked in a branch checked out from
> >>>> develop and when done merged back.
> >>>>
> >>>> In my opinion, for any case developers should not work on any of
> >>>> the branches (master, release, develop) directly but checkout
> >>>> branch and
> >> work
> >>>> on it and merge back (or cherry-pick or squash merge) to respective
> >>>> branch only when their work is complete, with unit tests and
> >>>> validated using unit testing and smoke tests (BVT).
> >>>>
> >>>>> We should decide:
> >>>>> for which bugs the hot fix branch should be cut, and which fixes
> >>>>> can go directly to *develop/*release branches. This criteria has
> >>>>> to be defined in the doc, and be based on the a) bug severity b)
> >>>>> number of people who work on the bug - if more than one, then we
> >>>>> cut the new branch c) feedback/review is needed for the bug d)
> >>>>> anything else?
> >>>>
> >>>> What you suggest is fine. I think couple of areas which can qualify
> >>>> for bugfixes (hotfixes) would be related to security, database
> >>>> changes, systemvms, agent, hypervisor, network, storage, anything
> >>>> that could be considered a blocker.
> >>>>
> >>>> I¹m not sure but I think adopting nvie could possibly affect our
> >>>> release process, I would let PMC and experienced RMs to comment on
> >>>> this issue
> >> and
> >>>> if they would like any modifications to the release process?
> >>>>
> >>>> On twitter I asked @nvie if he would have any change in the nvie
> >>>> model, he has a short reply:
> >>>> https://twitter.com/nvie/status/494870892917563393
> >>>>
> >>>> 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.
> >>
> >
> >
> >
> > --
> >
> >
> > *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] git workflow

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

On Aug 1, 2014, at 10:30 AM, Nate Gordon <na...@appcore.com> wrote:

> +1
> 
> On CI, I think it should run on any branch that wants to maintain quality.
> So master, develop, releases, hotfixes, and support. It would be awesome if
> I could elect to have my random other branches run CI as well, but my guess
> is that we would need more hardware to pull that off. Hopefully I'll have
> some extra hardware to donate to the cause in the next few months, but need
> to get everything currently on it moved somewhere else first.
> 

FWIW, a few of us are looking at a TravisCI setup to run the simulator. Assuming the tests would run quickly (< 60 minutes on travis hardware), we could have tests run on every commit for every branch mirrored on github (…I hear some of you say "yeah right…"). But imho that would be an ideal scenario, as folks own fork could also run the simulator automatically.
Will see if we get anywhere with this.

> 
> On Fri, Aug 1, 2014 at 5:37 AM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
> 
>> 
>> On 01-Aug-2014, at 1:40 am, Alena Prokharchyk <
>> Alena.Prokharchyk@citrix.com> wrote:
>> 
>>> Thank you, Rohit. Couple more things we have to clarify in the wiki. The
>>> doc says "Developer should run the BVT on the simulator before doing a
>>> checkin², but it doesn¹t mention anything about the CI. So here are my
>>> questions:
>>> 
>>> 1) CI execution
>>> 
>>> * on which branches we are planning to run the CI
>>> * with what frequency
>> 
>> Automated systems will be there for main branches such as develop, master,
>> release etc.
>> 
>> The frequency would vary, the best I’m able to get on my local lab is 50
>> mins per BVT run (advanced).
>> 
>> For feature, bug fix, developer’s personal branches developers can setup a
>> CI with Travis, Azure (Edison says free subscription is available), AWS
>> (free-tier) etc. at least say once a day run the BVTs on their
>> laptop/desktop before pushing the code to their remote branch.
>> 
>>> 
>>> 2) Reverting the fixes breaking the CI - are we planning to do it? If so,
>>> would it be done automatically after CI run, or developer should do it
>>> himself?
>> 
>> I think a human should do it.
>> In the past we’ve seen developer revert breaking commit(s) and reaching
>> out to the author/community about it.
>> 
>> Regards.
>> 
>>> 
>>> 
>>> -Alena.
>>> 
>>> On 7/31/14, 4:28 PM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>>> 
>>>> Comments in-line;
>>>> 
>>>> On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk
>>>> <Al...@citrix.com> wrote:
>>>> 
>>>>> Done, updated the wiki page with my comments. Copy/pasting here:
>>>>> 
>>>>> Open items:
>>>>> 1) Which bugs can be submitted to develop branch directly.
>>>>> Document http://nvie.com/posts/a-successful-git-branching-model/
>>>>> mentions
>>>>> that the
>>>>> *hotfix branch should be created for the blocker/critical bugs in the
>>>>> current production release. What about bugs happenning in the
>>>>> *release(the
>>>>> one that hasn't been released yet)/*develop
>>>>> branches ? Should we fix them directly in those branches, or should we
>>>>> branch out off the *release
>>>>> branch, fix the problem, and merge the fix to *release?
>>>> 
>>>> As per nvie;
>>>> 
>>>> once cut out release branches should only have bugfixes. So, bugfixes
>> can
>>>> directly land on release branch and then cherry-picked or merge to the
>>>> develop branch.
>>>> 
>>>> For bugs on develop branch, the commits can land directly on the develop
>>>> branch or can be worked in a branch checked out from develop and when
>>>> done merged back.
>>>> 
>>>> In my opinion, for any case developers should not work on any of the
>>>> branches (master, release, develop) directly but checkout branch and
>> work
>>>> on it and merge back (or cherry-pick or squash merge) to respective
>>>> branch only when their work is complete, with unit tests and validated
>>>> using unit testing and smoke tests (BVT).
>>>> 
>>>>> We should decide:
>>>>> for which bugs the hot fix branch should be cut, and which fixes can go
>>>>> directly to *develop/*release branches. This criteria has to be defined
>>>>> in
>>>>> the doc, and be based on the a) bug severity b) number of people who
>>>>> work
>>>>> on the bug - if more than one, then we cut the new branch c)
>>>>> feedback/review is needed for the bug d) anything else?
>>>> 
>>>> What you suggest is fine. I think couple of areas which can qualify for
>>>> bugfixes (hotfixes) would be related to security, database changes,
>>>> systemvms, agent, hypervisor, network, storage, anything that could be
>>>> considered a blocker.
>>>> 
>>>> I¹m not sure but I think adopting nvie could possibly affect our release
>>>> process, I would let PMC and experienced RMs to comment on this issue
>> and
>>>> if they would like any modifications to the release process?
>>>> 
>>>> On twitter I asked @nvie if he would have any change in the nvie model,
>>>> he has a short reply:
>>>> https://twitter.com/nvie/status/494870892917563393
>>>> 
>>>> 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.
>> 
> 
> 
> 
> -- 
> 
> 
> *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] git workflow

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

+1

On CI, I think it should run on any branch that wants to maintain quality.
So master, develop, releases, hotfixes, and support. It would be awesome if
I could elect to have my random other branches run CI as well, but my guess
is that we would need more hardware to pull that off. Hopefully I'll have
some extra hardware to donate to the cause in the next few months, but need
to get everything currently on it moved somewhere else first.


On Fri, Aug 1, 2014 at 5:37 AM, Rohit Yadav <ro...@shapeblue.com>
wrote:

>
> On 01-Aug-2014, at 1:40 am, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
> > Thank you, Rohit. Couple more things we have to clarify in the wiki. The
> > doc says "Developer should run the BVT on the simulator before doing a
> > checkin², but it doesn¹t mention anything about the CI. So here are my
> > questions:
> >
> > 1) CI execution
> >
> > * on which branches we are planning to run the CI
> > * with what frequency
>
> Automated systems will be there for main branches such as develop, master,
> release etc.
>
> The frequency would vary, the best I’m able to get on my local lab is 50
> mins per BVT run (advanced).
>
> For feature, bug fix, developer’s personal branches developers can setup a
> CI with Travis, Azure (Edison says free subscription is available), AWS
> (free-tier) etc. at least say once a day run the BVTs on their
> laptop/desktop before pushing the code to their remote branch.
>
> >
> > 2) Reverting the fixes breaking the CI - are we planning to do it? If so,
> > would it be done automatically after CI run, or developer should do it
> > himself?
>
> I think a human should do it.
> In the past we’ve seen developer revert breaking commit(s) and reaching
> out to the author/community about it.
>
> Regards.
>
> >
> >
> > -Alena.
> >
> > On 7/31/14, 4:28 PM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
> >
> >> Comments in-line;
> >>
> >> On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk
> >> <Al...@citrix.com> wrote:
> >>
> >>> Done, updated the wiki page with my comments. Copy/pasting here:
> >>>
> >>> Open items:
> >>> 1) Which bugs can be submitted to develop branch directly.
> >>> Document http://nvie.com/posts/a-successful-git-branching-model/
> >>> mentions
> >>> that the
> >>> *hotfix branch should be created for the blocker/critical bugs in the
> >>> current production release. What about bugs happenning in the
> >>> *release(the
> >>> one that hasn't been released yet)/*develop
> >>> branches ? Should we fix them directly in those branches, or should we
> >>> branch out off the *release
> >>> branch, fix the problem, and merge the fix to *release?
> >>
> >> As per nvie;
> >>
> >> once cut out release branches should only have bugfixes. So, bugfixes
> can
> >> directly land on release branch and then cherry-picked or merge to the
> >> develop branch.
> >>
> >> For bugs on develop branch, the commits can land directly on the develop
> >> branch or can be worked in a branch checked out from develop and when
> >> done merged back.
> >>
> >> In my opinion, for any case developers should not work on any of the
> >> branches (master, release, develop) directly but checkout branch and
> work
> >> on it and merge back (or cherry-pick or squash merge) to respective
> >> branch only when their work is complete, with unit tests and validated
> >> using unit testing and smoke tests (BVT).
> >>
> >>> We should decide:
> >>> for which bugs the hot fix branch should be cut, and which fixes can go
> >>> directly to *develop/*release branches. This criteria has to be defined
> >>> in
> >>> the doc, and be based on the a) bug severity b) number of people who
> >>> work
> >>> on the bug - if more than one, then we cut the new branch c)
> >>> feedback/review is needed for the bug d) anything else?
> >>
> >> What you suggest is fine. I think couple of areas which can qualify for
> >> bugfixes (hotfixes) would be related to security, database changes,
> >> systemvms, agent, hypervisor, network, storage, anything that could be
> >> considered a blocker.
> >>
> >> I¹m not sure but I think adopting nvie could possibly affect our release
> >> process, I would let PMC and experienced RMs to comment on this issue
> and
> >> if they would like any modifications to the release process?
> >>
> >> On twitter I asked @nvie if he would have any change in the nvie model,
> >> he has a short reply:
> >> https://twitter.com/nvie/status/494870892917563393
> >>
> >> 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.
>



-- 


*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] git workflow

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

On 01-Aug-2014, at 1:40 am, Alena Prokharchyk <Al...@citrix.com> wrote:

> Thank you, Rohit. Couple more things we have to clarify in the wiki. The
> doc says "Developer should run the BVT on the simulator before doing a
> checkin², but it doesn¹t mention anything about the CI. So here are my
> questions:
>
> 1) CI execution
>
> * on which branches we are planning to run the CI
> * with what frequency

Automated systems will be there for main branches such as develop, master, release etc.

The frequency would vary, the best I’m able to get on my local lab is 50 mins per BVT run (advanced).

For feature, bug fix, developer’s personal branches developers can setup a CI with Travis, Azure (Edison says free subscription is available), AWS (free-tier) etc. at least say once a day run the BVTs on their laptop/desktop before pushing the code to their remote branch.

>
> 2) Reverting the fixes breaking the CI - are we planning to do it? If so,
> would it be done automatically after CI run, or developer should do it
> himself?

I think a human should do it.
In the past we’ve seen developer revert breaking commit(s) and reaching out to the author/community about it.

Regards.

>
>
> -Alena.
>
> On 7/31/14, 4:28 PM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>
>> Comments in-line;
>>
>> On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk
>> <Al...@citrix.com> wrote:
>>
>>> Done, updated the wiki page with my comments. Copy/pasting here:
>>>
>>> Open items:
>>> 1) Which bugs can be submitted to develop branch directly.
>>> Document http://nvie.com/posts/a-successful-git-branching-model/
>>> mentions
>>> that the
>>> *hotfix branch should be created for the blocker/critical bugs in the
>>> current production release. What about bugs happenning in the
>>> *release(the
>>> one that hasn't been released yet)/*develop
>>> branches ? Should we fix them directly in those branches, or should we
>>> branch out off the *release
>>> branch, fix the problem, and merge the fix to *release?
>>
>> As per nvie;
>>
>> once cut out release branches should only have bugfixes. So, bugfixes can
>> directly land on release branch and then cherry-picked or merge to the
>> develop branch.
>>
>> For bugs on develop branch, the commits can land directly on the develop
>> branch or can be worked in a branch checked out from develop and when
>> done merged back.
>>
>> In my opinion, for any case developers should not work on any of the
>> branches (master, release, develop) directly but checkout branch and work
>> on it and merge back (or cherry-pick or squash merge) to respective
>> branch only when their work is complete, with unit tests and validated
>> using unit testing and smoke tests (BVT).
>>
>>> We should decide:
>>> for which bugs the hot fix branch should be cut, and which fixes can go
>>> directly to *develop/*release branches. This criteria has to be defined
>>> in
>>> the doc, and be based on the a) bug severity b) number of people who
>>> work
>>> on the bug - if more than one, then we cut the new branch c)
>>> feedback/review is needed for the bug d) anything else?
>>
>> What you suggest is fine. I think couple of areas which can qualify for
>> bugfixes (hotfixes) would be related to security, database changes,
>> systemvms, agent, hypervisor, network, storage, anything that could be
>> considered a blocker.
>>
>> I¹m not sure but I think adopting nvie could possibly affect our release
>> process, I would let PMC and experienced RMs to comment on this issue and
>> if they would like any modifications to the release process?
>>
>> On twitter I asked @nvie if he would have any change in the nvie model,
>> he has a short reply:
>> https://twitter.com/nvie/status/494870892917563393
>>
>> 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] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Thank you, Rohit. Couple more things we have to clarify in the wiki. The
doc says "Developer should run the BVT on the simulator before doing a
checkin², but it doesn¹t mention anything about the CI. So here are my
questions:
 
1) CI execution

* on which branches we are planning to run the CI
* with what frequency

2) Reverting the fixes breaking the CI - are we planning to do it? If so,
would it be done automatically after CI run, or developer should do it
himself?


-Alena.

On 7/31/14, 4:28 PM, "Rohit Yadav" <ro...@shapeblue.com> wrote:

>Comments in-line;
>
>On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk
><Al...@citrix.com> wrote:
>
>> Done, updated the wiki page with my comments. Copy/pasting here:
>>
>> Open items:
>> 1) Which bugs can be submitted to develop branch directly.
>> Document http://nvie.com/posts/a-successful-git-branching-model/
>>mentions
>> that the
>> *hotfix branch should be created for the blocker/critical bugs in the
>> current production release. What about bugs happenning in the
>>*release(the
>> one that hasn't been released yet)/*develop
>> branches ? Should we fix them directly in those branches, or should we
>> branch out off the *release
>> branch, fix the problem, and merge the fix to *release?
>
>As per nvie;
>
>once cut out release branches should only have bugfixes. So, bugfixes can
>directly land on release branch and then cherry-picked or merge to the
>develop branch.
>
>For bugs on develop branch, the commits can land directly on the develop
>branch or can be worked in a branch checked out from develop and when
>done merged back.
>
>In my opinion, for any case developers should not work on any of the
>branches (master, release, develop) directly but checkout branch and work
>on it and merge back (or cherry-pick or squash merge) to respective
>branch only when their work is complete, with unit tests and validated
>using unit testing and smoke tests (BVT).
>
>> We should decide:
>> for which bugs the hot fix branch should be cut, and which fixes can go
>> directly to *develop/*release branches. This criteria has to be defined
>>in
>> the doc, and be based on the a) bug severity b) number of people who
>>work
>> on the bug - if more than one, then we cut the new branch c)
>> feedback/review is needed for the bug d) anything else?
>
>What you suggest is fine. I think couple of areas which can qualify for
>bugfixes (hotfixes) would be related to security, database changes,
>systemvms, agent, hypervisor, network, storage, anything that could be
>considered a blocker.
>
>I¹m not sure but I think adopting nvie could possibly affect our release
>process, I would let PMC and experienced RMs to comment on this issue and
>if they would like any modifications to the release process?
>
>On twitter I asked @nvie if he would have any change in the nvie model,
>he has a short reply:
>https://twitter.com/nvie/status/494870892917563393
>
>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] git workflow

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

Comments in-line;

On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk <Al...@citrix.com> wrote:

> Done, updated the wiki page with my comments. Copy/pasting here:
>
> Open items:
> 1) Which bugs can be submitted to develop branch directly.
> Document http://nvie.com/posts/a-successful-git-branching-model/ mentions
> that the
> *hotfix branch should be created for the blocker/critical bugs in the
> current production release. What about bugs happenning in the *release(the
> one that hasn't been released yet)/*develop
> branches ? Should we fix them directly in those branches, or should we
> branch out off the *release
> branch, fix the problem, and merge the fix to *release?

As per nvie;

once cut out release branches should only have bugfixes. So, bugfixes can directly land on release branch and then cherry-picked or merge to the develop branch.

For bugs on develop branch, the commits can land directly on the develop branch or can be worked in a branch checked out from develop and when done merged back.

In my opinion, for any case developers should not work on any of the branches (master, release, develop) directly but checkout branch and work on it and merge back (or cherry-pick or squash merge) to respective branch only when their work is complete, with unit tests and validated using unit testing and smoke tests (BVT).

> We should decide:
> for which bugs the hot fix branch should be cut, and which fixes can go
> directly to *develop/*release branches. This criteria has to be defined in
> the doc, and be based on the a) bug severity b) number of people who work
> on the bug - if more than one, then we cut the new branch c)
> feedback/review is needed for the bug d) anything else?

What you suggest is fine. I think couple of areas which can qualify for bugfixes (hotfixes) would be related to security, database changes, systemvms, agent, hypervisor, network, storage, anything that could be considered a blocker.

I’m not sure but I think adopting nvie could possibly affect our release process, I would let PMC and experienced RMs to comment on this issue and if they would like any modifications to the release process?

On twitter I asked @nvie if he would have any change in the nvie model, he has a short reply:
https://twitter.com/nvie/status/494870892917563393

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] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

Done, updated the wiki page with my comments. Copy/pasting here:

Open items:
1) Which bugs can be submitted to develop branch directly.
Document http://nvie.com/posts/a-successful-git-branching-model/ mentions
that the
*hotfix branch should be created for the blocker/critical bugs in the
current production release. What about bugs happenning in the *release(the
one that hasn't been released yet)/*develop
branches ? Should we fix them directly in those branches, or should we
branch out off the *release
branch, fix the problem, and merge the fix to *release?
We should decide:
for which bugs the hot fix branch should be cut, and which fixes can go
directly to *develop/*release branches. This criteria has to be defined in
the doc, and be based on the a) bug severity b) number of people who work
on the bug - if more than one, then we cut the new branch c)
feedback/review is needed for the bug d) anything else?

2) I don't agree with the model when the person has to merge his
branch/commit the fix to both develop/master branches. So there are 2
approaches that can be taken:
* Currently proposed approach: ask a person always put 2 fixes - one in
master and one in develop
* Approach I suggest, and its used in the field a lot: Person commits the
fixes to *develop branch, and then there is some job doing automatic merge
from *develop to *master branch after CI on *develop passes

From the past experience, I see that the first (currently proposed)
approach is less desirable as a) sometimes people forget to push changes
into master branch, and then the release manager has to run the merge to
find those missing pieces b) IMPORTANT: it would require to run CI on both
*develop and *master branch with higher frequency, plus the rollbacks in
case of failure need to be done both in develop and master branches. I
would advocate for the following flow:

* submit fixes/merges from release/hotfix branches to *develop branch only
* Run daily(?) CI on develop branch, and do merge delta to master branch
only when CI passes

-Alena.






On 7/31/14, 1:40 PM, "Sebastien Goasguen" <ru...@gmail.com> wrote:

>
>On Jul 31, 2014, at 4:33 PM, Alena Prokharchyk
><Al...@citrix.com> wrote:
>
>> +1 on the proposal. But I second Rohit and Sheng Yang - we should agree
>>on
>> all the flow points before we adopt it for CloudStack. We can¹t just
>> blindly follow http://nvie.com/posts/a-successful-git-branching-model/,
>> plus some use cases are not explained there as I¹ve pointed in one of my
>> previous emails.
>> 
>
>Can you add to the wiki page then ? describe the use case that you have
>in mind and explain how to address it.
>
>If we all collaboratively edit that page we should be able to get to a
>consensus and have something that addresses all our current concerns.
>
>
>> -Alena.
>> 
>> On 7/31/14, 4:19 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
>> 
>>> +1
>>> 
>>> Hugo, I think we started this voting thread to get opinion on the
>>> proposal. I feel it may need some iteration and community agreement
>>> before we adopt it.
>>> 
>>> Suggestions, flames and opinions are welcome.
>>> 
>>> Regards.
>>> 
>>> 
>>> On 31-Jul-2014, at 12:43 pm, Hugo Trippaers <hu...@trippaers.nl> wrote:
>>> 
>>>> Rajani,
>>>> 
>>>> To make it clear for everyone. This is the vote to adopt this new way
>>>> of working right? Or is it just to get an opinion on the proposal?
>>>> 
>>>> If it is indeed the vote to adopt this way of working it means that
>>>>all
>>>> committers will change how we interact with the branches in the
>>>> CloudStack git.
>>>> 
>>>> It¹s is a good thing in my book, but we need to be clear what the
>>>> expected result is when this vote has concluded in 72 hours.
>>>> 
>>>> Cheers,
>>>> 
>>>> Hugo
>>>> 
>>>> 
>>>> On 31 jul. 2014, at 12:28, Rajani Karuturi
>>>><Ra...@citrix.com>
>>>> wrote:
>>>> 
>>>>> Hi All,
>>>>> 
>>>>> We had long discussions on the git flow.
>>>>> I tried to capture the summary of it @
>>>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>>>> This is updated on wiki @
>>>>> 
>>>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-Propose
>>>>>dG
>>>>> itflowbasedCheck-inProcess and is up for a vote:
>>>>> 
>>>>> Can you share your opinion on the proposal?
>>>>> 
>>>>> [ ] +1  approve
>>>>> [ ] +0  no opinion
>>>>> [ ] -1  disapprove (and reason why)
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> ~Rajani
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 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] git workflow

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

On Jul 31, 2014, at 4:33 PM, Alena Prokharchyk <Al...@citrix.com> wrote:

> +1 on the proposal. But I second Rohit and Sheng Yang - we should agree on
> all the flow points before we adopt it for CloudStack. We can¹t just
> blindly follow http://nvie.com/posts/a-successful-git-branching-model/,
> plus some use cases are not explained there as I¹ve pointed in one of my
> previous emails.
> 

Can you add to the wiki page then ? describe the use case that you have in mind and explain how to address it.

If we all collaboratively edit that page we should be able to get to a consensus and have something that addresses all our current concerns.


> -Alena.
> 
> On 7/31/14, 4:19 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:
> 
>> +1
>> 
>> Hugo, I think we started this voting thread to get opinion on the
>> proposal. I feel it may need some iteration and community agreement
>> before we adopt it.
>> 
>> Suggestions, flames and opinions are welcome.
>> 
>> Regards.
>> 
>> 
>> On 31-Jul-2014, at 12:43 pm, Hugo Trippaers <hu...@trippaers.nl> wrote:
>> 
>>> Rajani,
>>> 
>>> To make it clear for everyone. This is the vote to adopt this new way
>>> of working right? Or is it just to get an opinion on the proposal?
>>> 
>>> If it is indeed the vote to adopt this way of working it means that all
>>> committers will change how we interact with the branches in the
>>> CloudStack git.
>>> 
>>> It¹s is a good thing in my book, but we need to be clear what the
>>> expected result is when this vote has concluded in 72 hours.
>>> 
>>> Cheers,
>>> 
>>> Hugo
>>> 
>>> 
>>> On 31 jul. 2014, at 12:28, Rajani Karuturi <Ra...@citrix.com>
>>> wrote:
>>> 
>>>> Hi All,
>>>> 
>>>> We had long discussions on the git flow.
>>>> I tried to capture the summary of it @
>>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>>> This is updated on wiki @
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedG
>>>> itflowbasedCheck-inProcess and is up for a vote:
>>>> 
>>>> Can you share your opinion on the proposal?
>>>> 
>>>> [ ] +1  approve
>>>> [ ] +0  no opinion
>>>> [ ] -1  disapprove (and reason why)
>>>> 
>>>> 
>>>> Thanks,
>>>> ~Rajani
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 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] git workflow

[Alena Prokharchyk <Al...@citrix.com>]

+1 on the proposal. But I second Rohit and Sheng Yang - we should agree on
all the flow points before we adopt it for CloudStack. We can¹t just
blindly follow http://nvie.com/posts/a-successful-git-branching-model/,
plus some use cases are not explained there as I¹ve pointed in one of my
previous emails.

-Alena.

On 7/31/14, 4:19 AM, "Rohit Yadav" <ro...@shapeblue.com> wrote:

>+1
>
>Hugo, I think we started this voting thread to get opinion on the
>proposal. I feel it may need some iteration and community agreement
>before we adopt it.
>
>Suggestions, flames and opinions are welcome.
>
>Regards.
>
>
>On 31-Jul-2014, at 12:43 pm, Hugo Trippaers <hu...@trippaers.nl> wrote:
>
>> Rajani,
>>
>> To make it clear for everyone. This is the vote to adopt this new way
>>of working right? Or is it just to get an opinion on the proposal?
>>
>> If it is indeed the vote to adopt this way of working it means that all
>>committers will change how we interact with the branches in the
>>CloudStack git.
>>
>> It¹s is a good thing in my book, but we need to be clear what the
>>expected result is when this vote has concluded in 72 hours.
>>
>> Cheers,
>>
>> Hugo
>>
>>
>> On 31 jul. 2014, at 12:28, Rajani Karuturi <Ra...@citrix.com>
>>wrote:
>>
>>> Hi All,
>>>
>>> We had long discussions on the git flow.
>>> I tried to capture the summary of it @
>>>http://markmail.org/message/j5z7dxjcqxfkfhpj
>>> This is updated on wiki @
>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedG
>>>itflowbasedCheck-inProcess and is up for a vote:
>>>
>>> Can you share your opinion on the proposal?
>>>
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>>
>>>
>>> Thanks,
>>> ~Rajani
>>>
>>>
>>>
>>
>
>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] git workflow

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

+1

Hugo, I think we started this voting thread to get opinion on the proposal. I feel it may need some iteration and community agreement before we adopt it.

Suggestions, flames and opinions are welcome.

Regards.


On 31-Jul-2014, at 12:43 pm, Hugo Trippaers <hu...@trippaers.nl> wrote:

> Rajani,
>
> To make it clear for everyone. This is the vote to adopt this new way of working right? Or is it just to get an opinion on the proposal?
>
> If it is indeed the vote to adopt this way of working it means that all committers will change how we interact with the branches in the CloudStack git.
>
> It’s is a good thing in my book, but we need to be clear what the expected result is when this vote has concluded in 72 hours.
>
> Cheers,
>
> Hugo
>
>
> On 31 jul. 2014, at 12:28, Rajani Karuturi <Ra...@citrix.com> wrote:
>
>> Hi All,
>>
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @ http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote:
>>
>> Can you share your opinion on the proposal?
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>>
>> Thanks,
>> ~Rajani
>>
>>
>>
>

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] git workflow

[Hugo Trippaers <hu...@trippaers.nl>]

Rajani,

To make it clear for everyone. This is the vote to adopt this new way of working right? Or is it just to get an opinion on the proposal?

If it is indeed the vote to adopt this way of working it means that all committers will change how we interact with the branches in the CloudStack git.  

It’s is a good thing in my book, but we need to be clear what the expected result is when this vote has concluded in 72 hours. 

Cheers,

Hugo


On 31 jul. 2014, at 12:28, Rajani Karuturi <Ra...@citrix.com> wrote:

> Hi All,
> 
> We had long discussions on the git flow.
> I tried to capture the summary of it @ http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote:
> 
> Can you share your opinion on the proposal?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> 
> Thanks,
> ~Rajani
> 
> 
> 

Re: [VOTE] git workflow

[Tanner Danzey <ar...@gmail.com>]

+1


On Thu, Jul 31, 2014 at 5:28 AM, Rajani Karuturi <Rajani.Karuturi@citrix.com
> wrote:

> Hi All,
>
> We had long discussions on the git flow.
> I tried to capture the summary of it @
> http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
> and is up for a vote:
>
> Can you share your opinion on the proposal?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
>
> Thanks,
> ~Rajani
>
>
>
>


-- 
*Tanner Danzey*
Systems Engineer
Northstar Technology Group
arkaniad@gmail.com / tanner.danzey@northstar-tg.com
(701) 237-9096 x7122

Re: [VOTE] git workflow

[Sheng Yang <sh...@yasker.org>]

+0, based on my opinion on another thread "git commit process".

--Sheng

On Thu, Jul 31, 2014 at 10:56 AM, Mark Hinkle <Ma...@citrix.com>
wrote:

> +1
>
> Mark
>
>
> On Jul 31, 2014, at 12:03 PM, Sudha Ponnaganti <
> sudha.ponnaganti@citrix.com> wrote:
>
> > +1
> >
> > On Thu, Jul 31, 2014 at 12:28 PM, Rajani Karuturi <
> Rajani.Karuturi@citrix.com> wrote:
> >> Hi All,
> >>
> >> We had long discussions on the git flow.
> >> I tried to capture the summary of it @
> >> http://markmail.org/message/j5z7dxjcqxfkfhpj
> >> This is updated on wiki @
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
> and is up for a vote:
> >>
> >> Can you share your opinion on the proposal?
> >>
> >> [ ] +1  approve
> >> [ ] +0  no opinion
> >> [ ] -1  disapprove (and reason why)
> >>
> >>
> >> Thanks,
> >> ~Rajani
> >>
> >>
> >>
> >
> >
> >
> > --
> > Daan
>
>

Re: [VOTE] git workflow

[Mark Hinkle <Ma...@citrix.com>]

+1 

Mark


On Jul 31, 2014, at 12:03 PM, Sudha Ponnaganti <su...@citrix.com> wrote:

> +1
> 
> On Thu, Jul 31, 2014 at 12:28 PM, Rajani Karuturi <Ra...@citrix.com> wrote:
>> Hi All,
>> 
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @ 
>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote:
>> 
>> Can you share your opinion on the proposal?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> 
>> Thanks,
>> ~Rajani
>> 
>> 
>> 
> 
> 
> 
> --
> Daan

RE: [VOTE] git workflow

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

+1

On Thu, Jul 31, 2014 at 12:28 PM, Rajani Karuturi <Ra...@citrix.com> wrote:
> Hi All,
>
> We had long discussions on the git flow.
> I tried to capture the summary of it @ 
> http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote:
>
> Can you share your opinion on the proposal?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
>
> Thanks,
> ~Rajani
>
>
>



--
Daan

Re: [VOTE] git workflow

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

+1

On Thu, Jul 31, 2014 at 12:28 PM, Rajani Karuturi
<Ra...@citrix.com> wrote:
> Hi All,
>
> We had long discussions on the git flow.
> I tried to capture the summary of it @ http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote:
>
> Can you share your opinion on the proposal?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
>
> Thanks,
> ~Rajani
>
>
>



-- 
Daan

Re: [VOTE] git workflow

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

+1

-sebastien

On Jul 31, 2014, at 8:37 AM, Hugo Trippaers <hu...@trippaers.nl> wrote:

> +1 on the proposal
> 
> Cheers,
> 
> Hugo
> 
> 
> On 31 jul. 2014, at 14:31, Stephen Turner <St...@citrix.com> wrote:
> 
>> +1 from me.
>> 
>> -- 
>> Stephen Turner
>> 
>> 
>> -----Original Message-----
>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com] 
>> Sent: 31 July 2014 11:28
>> To: dev
>> Subject: [VOTE] git workflow
>> 
>> Hi All,
>> 
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @ http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote:
>> 
>> Can you share your opinion on the proposal?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> 
>> Thanks,
>> ~Rajani
>> 
>> 
>> 
> 

Re: [VOTE] git workflow

[Olivier Lemasle <ol...@apalia.net>]

+1 on the proposal.

Regards,

--
Olivier Lemasle
Apalia

On Thu, Jul 31, 2014 at 5:22 PM, Will Stevens <ws...@cloudops.com> wrote:

> +1
>
> Something that may need to be adjusted...
>
> If two different people are working on different hotfixes for 4.4, lets say
> they are for bugs CS-1234 and CS-5678, then in the current model they would
> both push their hotfix to 'hotfix/4.4.1'.  This will cause branch naming
> collisions which could be hard to work around.  I think we may want to
> adopt a hotfix branch name that reflects the bug the hotfix is related to.
>  So for the above example, the hotfix branches could be named something
> like 'hotfix/4.4.1-cs-1234' and 'hotfix/4.4.1-cs-5678'.  I don't think that
> two different committers work should go into the same 'hotfix/4.4.1' branch
> to be committed.  I think that will cause way too many issues...
>
> ws
>
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
>
> On Thu, Jul 31, 2014 at 11:03 AM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
> > +1
> >
> > On Thursday, July 31, 2014, Hugo Trippaers <hu...@trippaers.nl> wrote:
> >
> > > +1 on the proposal
> > >
> > > Cheers,
> > >
> > > Hugo
> > >
> > >
> > > On 31 jul. 2014, at 14:31, Stephen Turner <Stephen.Turner@citrix.com
> > > <javascript:;>> wrote:
> > >
> > > > +1 from me.
> > > >
> > > > --
> > > > Stephen Turner
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com
> > <javascript:;>]
> > > > Sent: 31 July 2014 11:28
> > > > To: dev
> > > > Subject: [VOTE] git workflow
> > > >
> > > > Hi All,
> > > >
> > > > We had long discussions on the git flow.
> > > > I tried to capture the summary of it @
> > > http://markmail.org/message/j5z7dxjcqxfkfhpj
> > > > This is updated on wiki @
> > >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
> > > and is up for a vote:
> > > >
> > > > Can you share your opinion on the proposal?
> > > >
> > > > [ ] +1  approve
> > > > [ ] +0  no opinion
> > > > [ ] -1  disapprove (and reason why)
> > > >
> > > >
> > > > Thanks,
> > > > ~Rajani
> > > >
> > > >
> > > >
> > >
> > >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkowski@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > <http://solidfire.com/solution/overview/?video=play>*™*
> >
>



-- 
Olivier Lemasle
Ingénieur Logiciel
*Apalia*™
Mobile: +33-611-69-12-11

*http://www.apalia.net <http://www.apalia.net>
<ol...@apalia.net>olivier.lemasle@apalia.net
<ol...@apalia.net>*

Re: [VOTE] git workflow

[Will Stevens <ws...@cloudops.com>]

+1

Something that may need to be adjusted...

If two different people are working on different hotfixes for 4.4, lets say
they are for bugs CS-1234 and CS-5678, then in the current model they would
both push their hotfix to 'hotfix/4.4.1'.  This will cause branch naming
collisions which could be hard to work around.  I think we may want to
adopt a hotfix branch name that reflects the bug the hotfix is related to.
 So for the above example, the hotfix branches could be named something
like 'hotfix/4.4.1-cs-1234' and 'hotfix/4.4.1-cs-5678'.  I don't think that
two different committers work should go into the same 'hotfix/4.4.1' branch
to be committed.  I think that will cause way too many issues...

ws


*Will STEVENS*
Lead Developer

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


On Thu, Jul 31, 2014 at 11:03 AM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> +1
>
> On Thursday, July 31, 2014, Hugo Trippaers <hu...@trippaers.nl> wrote:
>
> > +1 on the proposal
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > On 31 jul. 2014, at 14:31, Stephen Turner <Stephen.Turner@citrix.com
> > <javascript:;>> wrote:
> >
> > > +1 from me.
> > >
> > > --
> > > Stephen Turner
> > >
> > >
> > > -----Original Message-----
> > > From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com
> <javascript:;>]
> > > Sent: 31 July 2014 11:28
> > > To: dev
> > > Subject: [VOTE] git workflow
> > >
> > > Hi All,
> > >
> > > We had long discussions on the git flow.
> > > I tried to capture the summary of it @
> > http://markmail.org/message/j5z7dxjcqxfkfhpj
> > > This is updated on wiki @
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
> > and is up for a vote:
> > >
> > > Can you share your opinion on the proposal?
> > >
> > > [ ] +1  approve
> > > [ ] +0  no opinion
> > > [ ] -1  disapprove (and reason why)
> > >
> > >
> > > Thanks,
> > > ~Rajani
> > >
> > >
> > >
> >
> >
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*
>

Re: [VOTE] git workflow

[Mike Tutkowski <mi...@solidfire.com>]

+1

On Thursday, July 31, 2014, Hugo Trippaers <hu...@trippaers.nl> wrote:

> +1 on the proposal
>
> Cheers,
>
> Hugo
>
>
> On 31 jul. 2014, at 14:31, Stephen Turner <Stephen.Turner@citrix.com
> <javascript:;>> wrote:
>
> > +1 from me.
> >
> > --
> > Stephen Turner
> >
> >
> > -----Original Message-----
> > From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com <javascript:;>]
> > Sent: 31 July 2014 11:28
> > To: dev
> > Subject: [VOTE] git workflow
> >
> > Hi All,
> >
> > We had long discussions on the git flow.
> > I tried to capture the summary of it @
> http://markmail.org/message/j5z7dxjcqxfkfhpj
> > This is updated on wiki @
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
> and is up for a vote:
> >
> > Can you share your opinion on the proposal?
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> >
> > Thanks,
> > ~Rajani
> >
> >
> >
>
>

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Re: [VOTE] git workflow

[Hugo Trippaers <hu...@trippaers.nl>]

+1 on the proposal

Cheers,

Hugo


On 31 jul. 2014, at 14:31, Stephen Turner <St...@citrix.com> wrote:

> +1 from me.
> 
> -- 
> Stephen Turner
> 
> 
> -----Original Message-----
> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com] 
> Sent: 31 July 2014 11:28
> To: dev
> Subject: [VOTE] git workflow
> 
> Hi All,
> 
> We had long discussions on the git flow.
> I tried to capture the summary of it @ http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote:
> 
> Can you share your opinion on the proposal?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> 
> Thanks,
> ~Rajani
> 
> 
> 

RE: [VOTE] git workflow

[Stephen Turner <St...@citrix.com>]

+1 from me.

-- 
Stephen Turner


-----Original Message-----
From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com] 
Sent: 31 July 2014 11:28
To: dev
Subject: [VOTE] git workflow

Hi All,

We had long discussions on the git flow.
I tried to capture the summary of it @ http://markmail.org/message/j5z7dxjcqxfkfhpj
This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote:

Can you share your opinion on the proposal?

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


Thanks,
~Rajani

RE: [RESULT][VOTE] git workflow

[Suresh Sadhu <Su...@citrix.com>]

+1 

-----Original Message-----
From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com] 
Sent: 04 August 2014 10:07
To: dev@cloudstack.apache.org
Subject: [RESULT][VOTE] git workflow

There were 17 votes on the proposal

+1 15 people
+0 2 people
-1 none

Thanks everyone for participating.

The only open question I see in the thread is about hot fix branch naming convention.
Since there aren't any major concerns and the vote has passed, I believe we should start adopting to this.

Sebastian/Daan/Hugo
Can we start on following this and make the necessary git branches?


Thanks,
~Rajani



On 31-Jul-2014, at 3:58 pm, Rajani Karuturi <Ra...@citrix.com> wrote:

> Hi All,
> 
> We had long discussions on the git flow.
> I tried to capture the summary of it @ http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote:
> 
> Can you share your opinion on the proposal?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> 
> Thanks,
> ~Rajani
> 
> 
> 

[RESULT][VOTE] git workflow

[Rajani Karuturi <Ra...@citrix.com>]

There were 17 votes on the proposal

+1 15 people
+0 2 people
-1 none

Thanks everyone for participating.

The only open question I see in the thread is about hot fix branch naming convention.
Since there aren’t any major concerns and the vote has passed, I believe we should start adopting to this.

Sebastian/Daan/Hugo
Can we start on following this and make the necessary git branches?


Thanks,
~Rajani



On 31-Jul-2014, at 3:58 pm, Rajani Karuturi <Ra...@citrix.com> wrote:

> Hi All,
> 
> We had long discussions on the git flow.
> I tried to capture the summary of it @ http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote:
> 
> Can you share your opinion on the proposal?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> 
> Thanks,
> ~Rajani
> 
> 
> 

Re: [VOTE] git workflow

[Leo Simons <LS...@schubergphilis.com>]

On Jul 31, 2014, at 12:28 PM, Rajani Karuturi <Ra...@citrix.com> wrote:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
...
> is up for a vote:

+1

- Leo