[PROPOSAL] git workflow

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

Hi all,



Our current git workflow is confusing with the *forward branches and cherry-picking. Its hard to track on what all releases the commit has gone into unless I do some git log greping. Also, as a contributor, I endup creating patches for each branch as it doesn’t cleanly apply on different branches.



I think we should have some guidelines. Here is what I propose.



  1.  There should be branch for every major release(ex: 4.3.x, 4.4.x, 5.0.x,5.1.x) and the minor releases should be tagged accordingly on the respective branches.
  2.  The branch naming convention is to be followed. Many branches with 4.3, 4.3.0, 4.3.1 etc. is confusing
  3.  Cherry-picking should be avoided. In git, when we cherry-pick, we have two physically distinct commits for the same change or fix and is difficult to track unless you do cherry-pick -x
  4.  There should always be a continous flow from release branches to master. This doesn’t mean cherry-picking. They should be merged(either ff or no-ff) which retains the commit ids and easily trackable with git branch --contains
     *   Every bug fix should always flow from minimal release uptill master. A bug isnt fixed until the fix reaches master.
     *   For ex. A bug 4.2.1 should be committed to 4.2.x->4.3.x->4.4.x->master
     *   If someone forgets to do the merge, the next time a new commit is done this will also get merged.
  5.  There should always be a continuous flow from master to feature branches. Meaning all feature branch owners should proactively take any new commits from master by doing a merge from master
  6.  The commits from feature branch will make to master on code complete through a merge.
  7.  There should never be a merge from master to release branches
  8.  Every commit in LTS branch(targetted to any minor release) should have atleast bug id and correct author information
     *   Cassandra's template: patch by <author>; reviewed by <committer> for CASSANDRA-<ticket>
  9.  Once the release branch is created(after code freeze), any bug in jira can be marked with fix version current release(4.4) only on RM's approval and only they can go to the release branch.  This can be done through jira and with certain rules.(may be using jira vote?) this would save the cherry-picking time and another branch maintenance.



Please add your thoughts/suggestions/comments.



Ref:
http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
https://www.youtube.com/watch?v=AJ-CpGsCpM0

~Rajani

Re: [DISCUSS][PROPOSAL] git workflow

[Marcus <sh...@gmail.com>]

Is that not happening?


On Mon, Jun 2, 2014 at 11:26 AM, David Nalley <da...@gnsa.us> wrote:

> On Mon, Jun 2, 2014 at 1:21 PM, Marcus <sh...@gmail.com> wrote:
> > I think many of the bullet points are what we are currently doing
> > (guidelines for commit comments, feature branches need to stay in sync
> with
> > master, no back-merging). I also think that much of what we do now is
> done
> > the way it is simply because there *are* vast changes between versions.
> > Classes are getting shuffled around and changed all the time. If its
> > feasible to merge branch fixes to master, that's fine, but some quick
> tests
> > seem to indicate that this will be messy getting started.
> >
> > That leaves us with how we do releases. I'm fine with having single
> > branches for major releases(4.3) and tagging the commits where each
> > incremental release (4.3.x) is done. I'm trying to remember why we went
> > with the -forward, I'm sure it's in the mailing list somewhere, but one
> of
> > the nice things it provides is the ability for the release manager to
> > control what changes are made during code freeze while giving people a
> > place to stage fixes (though admittedly this is not always followed).
> > Without -forward, would the flow be for each dev to have their own repo
> and
> > issue pull requests for bugfixes?
> >
>
> The historical reasoning was that we needed to keep 4.x relatively
> clean, particularly as we were voting on RCs, but we didn't want to
> stop folks working on bugs, even if they were minor and getting those
> ready for 4.x.1; otherwise 4.x effectively becomes abandoned from a
> bug fix perspective.
>
> What should (IMO) be happening is 4.x-forward should be getting merged
> into 4.x as soon as the release is kicked out the door, and then
> 4.x-forward deleted.
>
> --David
>

Re: [DISCUSS][PROPOSAL] git workflow

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

On Mon, Jun 2, 2014 at 1:21 PM, Marcus <sh...@gmail.com> wrote:
> I think many of the bullet points are what we are currently doing
> (guidelines for commit comments, feature branches need to stay in sync with
> master, no back-merging). I also think that much of what we do now is done
> the way it is simply because there *are* vast changes between versions.
> Classes are getting shuffled around and changed all the time. If its
> feasible to merge branch fixes to master, that's fine, but some quick tests
> seem to indicate that this will be messy getting started.
>
> That leaves us with how we do releases. I'm fine with having single
> branches for major releases(4.3) and tagging the commits where each
> incremental release (4.3.x) is done. I'm trying to remember why we went
> with the -forward, I'm sure it's in the mailing list somewhere, but one of
> the nice things it provides is the ability for the release manager to
> control what changes are made during code freeze while giving people a
> place to stage fixes (though admittedly this is not always followed).
> Without -forward, would the flow be for each dev to have their own repo and
> issue pull requests for bugfixes?
>

The historical reasoning was that we needed to keep 4.x relatively
clean, particularly as we were voting on RCs, but we didn't want to
stop folks working on bugs, even if they were minor and getting those
ready for 4.x.1; otherwise 4.x effectively becomes abandoned from a
bug fix perspective.

What should (IMO) be happening is 4.x-forward should be getting merged
into 4.x as soon as the release is kicked out the door, and then
4.x-forward deleted.

--David

Re: [DISCUSS][PROPOSAL] git workflow

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

Hi,

Rajani Karuturi wrote:
> In my first email, I mentioned a youtube url[1] which is a google tech talk by  Laura Wingerd [2] of Perforce Software
> I recommend watching it as well. (its a 55 min video).
>
> [1] https://www.youtube.com/watch?v=AJ-CpGsCpM0
> [2] http://www.perforce.com/blog/author/lwingerd
>
> ~Rajani

Thanks for sharing this again Rajani, I saw the video it was insightful.

Here are the slides: (link on youtube was broken)

http://web.archive.org/web/20061019021704/http://www.perforce.com/perforce/conferences/us/2005/presentations/Wingerd.pdf


Let me share the key points from the shared talk:

- The speaker uses analogy of ease of driving cars on complex layout of
roads to developing software using a SCM.

- She recommends a mainline model which could speed up development and
release process. (refer the slides) We have branches -- mainline
(master), release (release branches) and development (feature work,
refactoring etc).

- Tofu scale: released/stable branches are firmer, unstable/master ones
are soft.

- She defines a baseline protocol: the soft branches are those which are
not tested and development work is going on, the firm ones are those
which are set to release or are already released or are live. The
protocol is to let the commit/changes flow from soft to firm branches
wrt to a baseline (master) only when they firm-er or tested and
continually changes flow from firm ones to soft ones (i.e. you rebase or
cherry-pick often from firm branches to soft ones). Change flows between
branch and baseline

- Always accept stable changes over destabilizing change

- She suggests to view the branches wrt baseline as a map, where changes
follow the baseline protocol and fix on an old trickle downs to
chronological release branches, then to baseline (master) and to rest of
the feature branches continually.

- She spoke about module, file tree etc. which I think is not relevant
for git users. We've git submodules and subtrees but IMO it's out of the
scope unless we want to split our repo.

- Merge down, copy up: She shares an interesting approach to deliver
feature work/project to firmer baseline branch which requires you to
first get all the changes from baselines (master & above, in git terms
that would be merge/rebase or cherry-picking from master to feature
branch) and then copy the files from the feature branch to baseline (not
merge). Then test and have the code/files in baseline (master).



My thoughts and suggestions:

- We adapt and adopt the baseline protocol (discuss?) wrt ACS

- We don't commit on master directly, break master. In future, have
master to be stable enough for anyone to branch off and work.

- Anyone fixing anything on master or other release/QA branches creates
a feature/topic branch and work on it, and merge/cherry-pick changes
back to upper branches only when that branch is well tested.

- Feature branches branch off master or other feature branches, not
release branches. Bug fix branches branch off from the oldest release
branch (on which we need to fix it) and the test fix lands to that
branch and subsequent release branches and then to master and other
feature branches.

- Suggestion for a better release protocol: All releases have tags. We
value tags more than release branch names. A vote is requested on a
release branch's commit with a version plus -RC, -beta and other
suitable name tag. Once vote is passed, the tag is the version number
this is the actual release. Git allows multiple tags can be on a commit
so we're good. Developers have freedmo to land but only bug fixes (once
fully tested) on release branches from a bugfix branch branched off from
the release branch or (by cherry-picking from) older release branches.
Then the bugfix lands to master and other feature branches continually.
This would also require that tags are immutable (you don't change/delete
them once created and pushed). IMHO this will speed up development process.

- One thing I'm still struggling with is working with branches/releases
which has fair amount of refactoring and rearchitecture work, which is
where changes would need to be manually ported and fixed. I don't have
any idea how to deal with it automatically, with git or any other tool.


> On 09-Jul-2014, at 3:52 am, Sebastien Goasguen<ru...@gmail.com>>  wrote:
>
> This is also a good read, against cherry-picking (back to Rajani's original point):
>
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>
> (even wondering if Rohit did not send this to the list already…)

I do not remember sharing this, but I've read posts like this before and
I think it's just the author's opinion and not universal truth.

In my experience, if you rebase your source branch and cherry pick on
target there is no issue or conflicts (as suggested by this articles).
If merge/rebase is required I prefer no-ff and ignore-whitespace flags.

Merging IMHO is a quick and easy solution but it clutters the history,
while cherry-picking is great tool to sample out small subset (I'm not
saying backport 1000s of commits using cherry-picking) of changes from a
topic or feature branch and also useful to backport changes, it fails at
keeping the same commit id for a fix/issue (i.e. when you cherry pick
they are added to target branch as new commits).

Sometimes both may not work, and things have to be backported manually
to branches/releases which feels like developing different software
products.

I think when our RMs cherry-pick from master to release branches
(current or older), they are back-porting changes so cherry-picking is a
valid tool (in which case merging is evil I think).

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | 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 is a registered trademark.

Re: [DISCUSS][PROPOSAL] git workflow

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

In my first email, I mentioned a youtube url[1] which is a google tech talk by  Laura Wingerd [2] of Perforce Software
I recommend watching it as well. (its a 55 min video).

[1] https://www.youtube.com/watch?v=AJ-CpGsCpM0
[2] http://www.perforce.com/blog/author/lwingerd

~Rajani



On 09-Jul-2014, at 3:52 am, Sebastien Goasguen <ru...@gmail.com>> wrote:

This is also a good read, against cherry-picking (back to Rajani's original point):

http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html

(even wondering if Rohit did not send this to the list already…)

-sebastien

Re: [DISCUSS][PROPOSAL] git workflow

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

On Jul 8, 2014, at 5:40 PM, Sebastien Goasguen <ru...@gmail.com> wrote:

> 
> On Jul 8, 2014, at 4:13 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
> 
>> Hi Chip,
>> 
>> Chip Childers wrote:
>>> Let me try that again, this time with content!
>>> 
>>> I've dropped private@, since this doesn't belong there.
>>> 
>>> On Tue, Jul 8, 2014 at 3:30 PM, Rohit Yadav<ro...@shapeblue.com>  wrote:
>>>> Hi,
>>>> 
>>>> 
>>>> Daan Hoogland wrote:
>>>>> I do not see why the PMC should drive defining the
>>>>> standard. This is something that should be carried and cherished by
>>>>> all developers.
>>>> 
>>>> In my experience when something is everyone's responsibility, eventually
>>>> no one is responsible for it.
>>>> 
>>>> I think the PMC should drive it because IMHO the PMC comprises of our
>>>> project management folks who have decision making powers and are
>>>> officially responsible for the project as recognized by the ASF [1].
>>>> 
>>>> Therefore, I'm requesting our PMC to come up with a convention along
>>>> with committers/developers on this issue and enforce it using some
>>>> tooling etc.
>>>> 
>>>> [1] http://www.apache.org/dev/pmc.htm
>>> 
>>> Everyone here is part of the community, and everyone deserves a say in
>>> how this is done.  If you're suggesting that PMC members should be
>>> involved in this discussion, agreed!  But should should committers and
>>> contributors!
>> 
>> Thanks Chip -- I'm with you on this.
>> 
>> I'm trying to say is -- shared responsibility is tricky, in most cases
>> no one would be responsible eventually, *unless*…
>> 
> 
> That's really a bar discussion :).
> 
> At Apache we govern by consensus. Any technical decisions (especially one like this), needs to be agreed upon by the community as a whole.
> The agreement will happen through discussion on the dev list. 
> 
> For us to change, we need people (who believe that what we are doing currently is wrong) to step up,  explain the issues and make a proposal.
> Then by iterating and discussing the proposal we will reach consensus.
> 
> At least that's how I view things.
> 
> I re-opened the thread because no-one picked it up, and as you say it's a shame.
> 
> IMHO our development methodology is totally broken and this is best shown by our inability to release on-time.
> 
> I am interested to take on the 4.5 or 4.6 RM duties if we agree to change our workflow significantly.
> 
> Personally, I would like to freeze master and make the development happen somewhere else.
> 
> Basically master should be our releasable branch and once we merge things in master we end up with working releases.
> I would go further and actually propose that only the RM gets to merge in master.
> 
> I think if we started from a working release tag it would mean that we would never miss a release on time. Only the scope of the features would be affected.
> 
> Until we have a proper review/test/commit CI setup we should not allow committing to master.
> 
> I am still thinking through this, but once I have a clear idea, I plan to make a proposal by writing a new workflow on the wiki.
> 
> ideas, thoughts, flames ?
> 
> -sebastien
> 

This is also a good read, against cherry-picking (back to Rajani's original point):

http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html

(even wondering if Rohit did not send this to the list already…)

-sebastien


> 
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +91 88 262 30892 | 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 is a registered trademark.
> 

Re: [DISCUSS][PROPOSAL] git workflow

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

On Jul 8, 2014, at 4:13 PM, Rohit Yadav <ro...@shapeblue.com> wrote:

> Hi Chip,
> 
> Chip Childers wrote:
>> Let me try that again, this time with content!
>> 
>> I've dropped private@, since this doesn't belong there.
>> 
>> On Tue, Jul 8, 2014 at 3:30 PM, Rohit Yadav<ro...@shapeblue.com>  wrote:
>>> Hi,
>>> 
>>> 
>>> Daan Hoogland wrote:
>>>> I do not see why the PMC should drive defining the
>>>> standard. This is something that should be carried and cherished by
>>>> all developers.
>>> 
>>> In my experience when something is everyone's responsibility, eventually
>>> no one is responsible for it.
>>> 
>>> I think the PMC should drive it because IMHO the PMC comprises of our
>>> project management folks who have decision making powers and are
>>> officially responsible for the project as recognized by the ASF [1].
>>> 
>>> Therefore, I'm requesting our PMC to come up with a convention along
>>> with committers/developers on this issue and enforce it using some
>>> tooling etc.
>>> 
>>> [1] http://www.apache.org/dev/pmc.htm
>> 
>> Everyone here is part of the community, and everyone deserves a say in
>> how this is done.  If you're suggesting that PMC members should be
>> involved in this discussion, agreed!  But should should committers and
>> contributors!
> 
> Thanks Chip -- I'm with you on this.
> 
> I'm trying to say is -- shared responsibility is tricky, in most cases
> no one would be responsible eventually, *unless*…
> 

That's really a bar discussion :).

At Apache we govern by consensus. Any technical decisions (especially one like this), needs to be agreed upon by the community as a whole.
The agreement will happen through discussion on the dev list. 

For us to change, we need people (who believe that what we are doing currently is wrong) to step up,  explain the issues and make a proposal.
Then by iterating and discussing the proposal we will reach consensus.

At least that's how I view things.

I re-opened the thread because no-one picked it up, and as you say it's a shame.

IMHO our development methodology is totally broken and this is best shown by our inability to release on-time.

I am interested to take on the 4.5 or 4.6 RM duties if we agree to change our workflow significantly.

Personally, I would like to freeze master and make the development happen somewhere else.

Basically master should be our releasable branch and once we merge things in master we end up with working releases.
I would go further and actually propose that only the RM gets to merge in master.

I think if we started from a working release tag it would mean that we would never miss a release on time. Only the scope of the features would be affected.

Until we have a proper review/test/commit CI setup we should not allow committing to master.

I am still thinking through this, but once I have a clear idea, I plan to make a proposal by writing a new workflow on the wiki.

ideas, thoughts, flames ?

-sebastien


> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | 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 is a registered trademark.

Re: [DISCUSS][PROPOSAL] git workflow

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

Hi Chip,

Chip Childers wrote:
> Let me try that again, this time with content!
>
> I've dropped private@, since this doesn't belong there.
>
> On Tue, Jul 8, 2014 at 3:30 PM, Rohit Yadav<ro...@shapeblue.com>  wrote:
>> Hi,
>>
>>
>> Daan Hoogland wrote:
>>> I do not see why the PMC should drive defining the
>>> standard. This is something that should be carried and cherished by
>>> all developers.
>>
>> In my experience when something is everyone's responsibility, eventually
>> no one is responsible for it.
>>
>> I think the PMC should drive it because IMHO the PMC comprises of our
>> project management folks who have decision making powers and are
>> officially responsible for the project as recognized by the ASF [1].
>>
>> Therefore, I'm requesting our PMC to come up with a convention along
>> with committers/developers on this issue and enforce it using some
>> tooling etc.
>>
>> [1] http://www.apache.org/dev/pmc.htm
>
> Everyone here is part of the community, and everyone deserves a say in
> how this is done.  If you're suggesting that PMC members should be
> involved in this discussion, agreed!  But should should committers and
> contributors!

Thanks Chip -- I'm with you on this.

I'm trying to say is -- shared responsibility is tricky, in most cases
no one would be responsible eventually, *unless*...

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | 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 is a registered trademark.

Re: [DISCUSS][PROPOSAL] git workflow

[Chip Childers <ch...@apache.org>]

Let me try that again, this time with content!

I've dropped private@, since this doesn't belong there.

On Tue, Jul 8, 2014 at 3:30 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hi,
>
>
> Daan Hoogland wrote:
>>
>> I do not see why the PMC should drive defining the
>> standard. This is something that should be carried and cherished by
>> all developers.
>
>
> In my experience when something is everyone's responsibility, eventually
> no one is responsible for it.
>
> I think the PMC should drive it because IMHO the PMC comprises of our
> project management folks who have decision making powers and are
> officially responsible for the project as recognized by the ASF [1].
>
> Therefore, I'm requesting our PMC to come up with a convention along
> with committers/developers on this issue and enforce it using some
> tooling etc.
>
> [1] http://www.apache.org/dev/pmc.htm

Everyone here is part of the community, and everyone deserves a say in
how this is done.  If you're suggesting that PMC members should be
involved in this discussion, agreed!  But should should committers and
contributors!

Re: [DISCUSS][PROPOSAL] git workflow

[Chip Childers <ch...@apache.org>]

On Tue, Jul 8, 2014 at 3:30 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hi,
>
>
> Daan Hoogland wrote:
>>
>> I do not see why the PMC should drive defining the
>> standard. This is something that should be carried and cherished by
>> all developers.
>
>
> In my experience when something is everyone's responsibility, eventually
> no one is responsible for it.
>
> I think the PMC should drive it because IMHO the PMC comprises of our
> project management folks who have decision making powers and are
> officially responsible for the project as recognized by the ASF [1].
>
> Therefore, I'm requesting our PMC to come up with a convention along
> with committers/developers on this issue and enforce it using some
> tooling etc.
>
> [1] http://www.apache.org/dev/pmc.htm
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | 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 is a registered
> trademark.

Re: [DISCUSS][PROPOSAL] git workflow

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

Hi,

Daan Hoogland wrote:
> I do not see why the PMC should drive defining the
> standard. This is something that should be carried and cherished by
> all developers.

In my experience when something is everyone's responsibility, eventually
no one is responsible for it.

I think the PMC should drive it because IMHO the PMC comprises of our
project management folks who have decision making powers and are
officially responsible for the project as recognized by the ASF [1].

Therefore, I'm requesting our PMC to come up with a convention along
with committers/developers on this issue and enforce it using some
tooling etc.

[1] http://www.apache.org/dev/pmc.htm

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | 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 is a registered trademark.

Re: [DISCUSS][PROPOSAL] git workflow

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

Rohit, I agree with most and I am glad to see you prefer cherry-pick
over merges. I do not see why the PMC should drive defining the
standard. This is something that should be carried and cherished by
all developers.

On Tue, Jul 8, 2014 at 9:51 AM, Rohit Yadav <bh...@apache.org> wrote:
> Hi,
>
>
> On Tue, Jul 1, 2014 at 3:39 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
>> I would like to re-start this discussion.
>>
>
> Such a shame, this is not getting any attention.
>
>
>>
>> Rajani made some good points and someone mentioned Gitflow:
>>
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> Thinking about our release procedure, we clearly need more tests and a CI.
>> However it looks like this is going to take some time.
>>
>
> I think too that this is going to take time, meanwhile a great way would be
> to self police?
>
> I would encourage every committer at least to learn to use git, handle git
> mess-ups, have a knowledge about various ACS 4.x branches, favour squashed
> commits and cherry-picking over branch merges, rebase on target branch
> (master) regularly, build often with unit tests before pushing to master
> (at least), test patches on local before merging them on master and other
> branches.
>
> @PMC: suggestion -- help drive defining a convention on committer workflow
> (refer nvie etc.), make it a requirement for all the committers (future and
> present) to learn/know (basic/novice) git, have knowledge about various ACS
> branches and release processes.
>
> Comments, suggestions?
>
> Regards.
>
>
>>
>> In the meantime I think there is nothing preventing us from agreeing to
>> 'git practices', we don't need tests or new infra, we just need to agree on
>> the git workflow.
>>
>> Right now Master is really a development branch, we should make it a
>> stable branch for production with very few commits.
>> This does not mean that we would release less, in contrary this would
>> ensure that a commit to master means it's a production release.
>>
>> In addition gitflow [1] does not do cherry-picks (gets back to Rajani's
>> point) everything is based on merges.
>>
>> I am of the opinion that git flow provides a nice process. It basically
>> freezes master. Development happens in a 'develop' branch, releases
>> branches are branched off of that and merged into master and back into
>> develop....etc
>>
>> Please read [1] it's a good read.
>>
>> And let's discuss,
>>
>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>
>> -Sebastien
>>
>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Ra...@citrix.com>
>> wrote:
>>
>> > There is also the problem of cherry-picking.
>> > As a contributor, I always endup creating multiple patches for each
>> branch as they don't cleanly apply on the upward branches. which means
>> distinct commits for each branch and I don't easily know which all branches
>> my commit exists unless I do grep.
>> > if we follow merging strategy properly, apart from the first merge of
>> the branch, everything else on top of it should be a painless merge.
>> >
>> >
>> >
>> > ~Rajani
>> >
>> >
>> >
>> > On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
>> >
>> >> I think many of the bullet points are what we are currently doing
>> >> (guidelines for commit comments, feature branches need to stay in sync
>> with
>> >> master, no back-merging). I also think that much of what we do now is
>> done
>> >> the way it is simply because there *are* vast changes between versions.
>> >> Classes are getting shuffled around and changed all the time. If its
>> >> feasible to merge branch fixes to master, that's fine, but some quick
>> tests
>> >> seem to indicate that this will be messy getting started.
>> >>
>> >> That leaves us with how we do releases. I'm fine with having single
>> >> branches for major releases(4.3) and tagging the commits where each
>> >> incremental release (4.3.x) is done. I'm trying to remember why we went
>> >> with the -forward, I'm sure it's in the mailing list somewhere, but one
>> of
>> >> the nice things it provides is the ability for the release manager to
>> >> control what changes are made during code freeze while giving people a
>> >> place to stage fixes (though admittedly this is not always followed).
>> >> Without -forward, would the flow be for each dev to have their own repo
>> and
>> >> issue pull requests for bugfixes?
>> >>
>> >>
>> >> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>> Rajani.Karuturi@citrix.com>
>> >> wrote:
>> >>
>> >>> Any other suggestions/objections/comments??
>> >>> Can we discuss this in detail and agree to a process??
>> >>>
>> >>>
>> >>> ~Rajani
>> >>>
>> >>>
>> >>>
>> >>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>> Rajani.Karuturi@citrix.com>
>> >>> wrote:
>> >>>
>> >>>> Yes as mike said, if its a one-off case we can do a empty merge(merge
>> -s
>> >>> ours) for it and git will assume its merged but will not bring in any
>> >>> changes.
>> >>>>
>> >>>> If the branches diverged a lot, for example after a major rewrite, we
>> >>> could stop merging to that branch and above and make the fix manually.
>> >>>>
>> >>>>
>> >>>> ~Rajani
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>> >>> mike.tutkowski@solidfire.com> wrote:
>> >>>>
>> >>>>> Yep, that's what I was referring to in that a particular fix for an
>> old
>> >>>>> release may not apply to newer versions. That does happen.
>> >>>>>
>> >>>>> We used to mark those as "don't need to merge to branch x" in SVN and
>> >>> then
>> >>>>> you handed it however made sense on the applicable branch(es).
>> >>>>>
>> >>>>>
>> >>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>> >>> Stephen.Turner@citrix.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> What happens if a fix isn't relevant for newer versions, or has to
>> be
>> >>>>>> rewritten for newer versions because the code has changed? Don't the
>> >>>>>> branches diverge and you end up cherry-picking after that?
>> >>>>>>
>> >>>>>> --
>> >>>>>> Stephen Turner
>> >>>>>>
>> >>>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>> >>>>>> Sent: 30 May 2014 18:48
>> >>>>>> To: dev@cloudstack.apache.org
>> >>>>>> Subject: Re: [PROPOSAL] git workflow
>> >>>>>>
>> >>>>>> I think this flow is something we should seriously consider.
>> >>>>>>
>> >>>>>> I find cherry picking from branch to branch to be error prone in
>> that
>> >>> it's
>> >>>>>> easy for someone to forget to cherry pick to all applicable branches
>> >>> and
>> >>>>>> you don't have any easy way to see the cherry picks are related.
>> >>>>>>
>> >>>>>> When I worked at HP, we had automated tools check to see if you
>> >>> checked a
>> >>>>>> fix into a prior release, but not later releases. In such a
>> situation,
>> >>> you
>> >>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
>> >>> longer
>> >>>>>> applicable in the later release(s), so you needed to mark it as
>> >>>>>> un-necessary (SVN supported this ability...not sure about Git).
>> >>>>>>
>> >>>>>>
>> >>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>> >>>>>> Rajani.Karuturi@citrix.com> wrote:
>> >>>>>>
>> >>>>>>> Hi all,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Our current git workflow is confusing with the *forward branches
>> and
>> >>>>>>> cherry-picking. Its hard to track on what all releases the commit
>> has
>> >>>>>>> gone into unless I do some git log greping. Also, as a
>> contributor, I
>> >>>>>>> endup creating patches for each branch as it doesn't cleanly apply
>> on
>> >>>>>>> different branches.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> I think we should have some guidelines. Here is what I propose.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
>> 4.4.x,
>> >>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on
>> >>>>>>> the respective branches.
>> >>>>>>> 2.  The branch naming convention is to be followed. Many branches
>> >>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>> >>>>>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
>> >>>>>>> we have two physically distinct commits for the same change or fix
>> and
>> >>>>>>> is difficult to track unless you do cherry-pick -x
>> >>>>>>> 4.  There should always be a continous flow from release branches
>> to
>> >>>>>>> master. This doesn't mean cherry-picking. They should be
>> merged(either
>> >>>>>>> ff or no-ff) which retains the commit ids and easily trackable with
>> >>>>>>> git branch --contains
>> >>>>>>>  *   Every bug fix should always flow from minimal release uptill
>> >>>>>>> master. A bug isnt fixed until the fix reaches master.
>> >>>>>>>  *   For ex. A bug 4.2.1 should be committed to
>> >>>>>>> 4.2.x->4.3.x->4.4.x->master
>> >>>>>>>  *   If someone forgets to do the merge, the next time a new commit
>> >>>>>> is
>> >>>>>>> done this will also get merged.
>> >>>>>>> 5.  There should always be a continuous flow from master to feature
>> >>>>>>> branches. Meaning all feature branch owners should proactively take
>> >>>>>>> any new commits from master by doing a merge from master
>> >>>>>>> 6.  The commits from feature branch will make to master on code
>> >>>>>>> complete through a merge.
>> >>>>>>> 7.  There should never be a merge from master to release branches
>> >>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>> >>>>>>> should have atleast bug id and correct author information
>> >>>>>>>  *   Cassandra's template: patch by <author>; reviewed by
>> >>> <committer>
>> >>>>>>> for CASSANDRA-<ticket>
>> >>>>>>> 9.  Once the release branch is created(after code freeze), any bug
>> >>>>>>> in jira can be marked with fix version current release(4.4) only on
>> >>>>>>> RM's approval and only they can go to the release branch.  This
>> can be
>> >>>>>>> done through jira and with certain rules.(may be using jira vote?)
>> >>>>>>> this would save the cherry-picking time and another branch
>> >>> maintenance.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Please add your thoughts/suggestions/comments.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Ref:
>> >>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>> >>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>> >>>>>>>
>> >>>>>>> ~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>*(tm)*
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> *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>*(tm)*
>> >>>>
>> >>>
>> >>>
>> >
>>
>>



-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

[Rohit Yadav <bh...@apache.org>]

Hi,


On Tue, Jul 1, 2014 at 3:39 AM, Sebastien Goasguen <ru...@gmail.com> wrote:

> I would like to re-start this discussion.
>

Such a shame, this is not getting any attention.


>
> Rajani made some good points and someone mentioned Gitflow:
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> Thinking about our release procedure, we clearly need more tests and a CI.
> However it looks like this is going to take some time.
>

I think too that this is going to take time, meanwhile a great way would be
to self police?

I would encourage every committer at least to learn to use git, handle git
mess-ups, have a knowledge about various ACS 4.x branches, favour squashed
commits and cherry-picking over branch merges, rebase on target branch
(master) regularly, build often with unit tests before pushing to master
(at least), test patches on local before merging them on master and other
branches.

@PMC: suggestion -- help drive defining a convention on committer workflow
(refer nvie etc.), make it a requirement for all the committers (future and
present) to learn/know (basic/novice) git, have knowledge about various ACS
branches and release processes.

Comments, suggestions?

Regards.


>
> In the meantime I think there is nothing preventing us from agreeing to
> 'git practices', we don't need tests or new infra, we just need to agree on
> the git workflow.
>
> Right now Master is really a development branch, we should make it a
> stable branch for production with very few commits.
> This does not mean that we would release less, in contrary this would
> ensure that a commit to master means it's a production release.
>
> In addition gitflow [1] does not do cherry-picks (gets back to Rajani's
> point) everything is based on merges.
>
> I am of the opinion that git flow provides a nice process. It basically
> freezes master. Development happens in a 'develop' branch, releases
> branches are branched off of that and merged into master and back into
> develop....etc
>
> Please read [1] it's a good read.
>
> And let's discuss,
>
> [1] http://nvie.com/posts/a-successful-git-branching-model/
>
> -Sebastien
>
> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Ra...@citrix.com>
> wrote:
>
> > There is also the problem of cherry-picking.
> > As a contributor, I always endup creating multiple patches for each
> branch as they don't cleanly apply on the upward branches. which means
> distinct commits for each branch and I don't easily know which all branches
> my commit exists unless I do grep.
> > if we follow merging strategy properly, apart from the first merge of
> the branch, everything else on top of it should be a painless merge.
> >
> >
> >
> > ~Rajani
> >
> >
> >
> > On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
> >
> >> I think many of the bullet points are what we are currently doing
> >> (guidelines for commit comments, feature branches need to stay in sync
> with
> >> master, no back-merging). I also think that much of what we do now is
> done
> >> the way it is simply because there *are* vast changes between versions.
> >> Classes are getting shuffled around and changed all the time. If its
> >> feasible to merge branch fixes to master, that's fine, but some quick
> tests
> >> seem to indicate that this will be messy getting started.
> >>
> >> That leaves us with how we do releases. I'm fine with having single
> >> branches for major releases(4.3) and tagging the commits where each
> >> incremental release (4.3.x) is done. I'm trying to remember why we went
> >> with the -forward, I'm sure it's in the mailing list somewhere, but one
> of
> >> the nice things it provides is the ability for the release manager to
> >> control what changes are made during code freeze while giving people a
> >> place to stage fixes (though admittedly this is not always followed).
> >> Without -forward, would the flow be for each dev to have their own repo
> and
> >> issue pull requests for bugfixes?
> >>
> >>
> >> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> Rajani.Karuturi@citrix.com>
> >> wrote:
> >>
> >>> Any other suggestions/objections/comments??
> >>> Can we discuss this in detail and agree to a process??
> >>>
> >>>
> >>> ~Rajani
> >>>
> >>>
> >>>
> >>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> Rajani.Karuturi@citrix.com>
> >>> wrote:
> >>>
> >>>> Yes as mike said, if its a one-off case we can do a empty merge(merge
> -s
> >>> ours) for it and git will assume its merged but will not bring in any
> >>> changes.
> >>>>
> >>>> If the branches diverged a lot, for example after a major rewrite, we
> >>> could stop merging to that branch and above and make the fix manually.
> >>>>
> >>>>
> >>>> ~Rajani
> >>>>
> >>>>
> >>>>
> >>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>> mike.tutkowski@solidfire.com> wrote:
> >>>>
> >>>>> Yep, that's what I was referring to in that a particular fix for an
> old
> >>>>> release may not apply to newer versions. That does happen.
> >>>>>
> >>>>> We used to mark those as "don't need to merge to branch x" in SVN and
> >>> then
> >>>>> you handed it however made sense on the applicable branch(es).
> >>>>>
> >>>>>
> >>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>> Stephen.Turner@citrix.com>
> >>>>> wrote:
> >>>>>
> >>>>>> What happens if a fix isn't relevant for newer versions, or has to
> be
> >>>>>> rewritten for newer versions because the code has changed? Don't the
> >>>>>> branches diverge and you end up cherry-picking after that?
> >>>>>>
> >>>>>> --
> >>>>>> Stephen Turner
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> >>>>>> Sent: 30 May 2014 18:48
> >>>>>> To: dev@cloudstack.apache.org
> >>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>
> >>>>>> I think this flow is something we should seriously consider.
> >>>>>>
> >>>>>> I find cherry picking from branch to branch to be error prone in
> that
> >>> it's
> >>>>>> easy for someone to forget to cherry pick to all applicable branches
> >>> and
> >>>>>> you don't have any easy way to see the cherry picks are related.
> >>>>>>
> >>>>>> When I worked at HP, we had automated tools check to see if you
> >>> checked a
> >>>>>> fix into a prior release, but not later releases. In such a
> situation,
> >>> you
> >>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
> >>> longer
> >>>>>> applicable in the later release(s), so you needed to mark it as
> >>>>>> un-necessary (SVN supported this ability...not sure about Git).
> >>>>>>
> >>>>>>
> >>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Our current git workflow is confusing with the *forward branches
> and
> >>>>>>> cherry-picking. Its hard to track on what all releases the commit
> has
> >>>>>>> gone into unless I do some git log greping. Also, as a
> contributor, I
> >>>>>>> endup creating patches for each branch as it doesn't cleanly apply
> on
> >>>>>>> different branches.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> I think we should have some guidelines. Here is what I propose.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
> 4.4.x,
> >>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on
> >>>>>>> the respective branches.
> >>>>>>> 2.  The branch naming convention is to be followed. Many branches
> >>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
> >>>>>>> we have two physically distinct commits for the same change or fix
> and
> >>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>> 4.  There should always be a continous flow from release branches
> to
> >>>>>>> master. This doesn't mean cherry-picking. They should be
> merged(either
> >>>>>>> ff or no-ff) which retains the commit ids and easily trackable with
> >>>>>>> git branch --contains
> >>>>>>>  *   Every bug fix should always flow from minimal release uptill
> >>>>>>> master. A bug isnt fixed until the fix reaches master.
> >>>>>>>  *   For ex. A bug 4.2.1 should be committed to
> >>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>  *   If someone forgets to do the merge, the next time a new commit
> >>>>>> is
> >>>>>>> done this will also get merged.
> >>>>>>> 5.  There should always be a continuous flow from master to feature
> >>>>>>> branches. Meaning all feature branch owners should proactively take
> >>>>>>> any new commits from master by doing a merge from master
> >>>>>>> 6.  The commits from feature branch will make to master on code
> >>>>>>> complete through a merge.
> >>>>>>> 7.  There should never be a merge from master to release branches
> >>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
> >>>>>>> should have atleast bug id and correct author information
> >>>>>>>  *   Cassandra's template: patch by <author>; reviewed by
> >>> <committer>
> >>>>>>> for CASSANDRA-<ticket>
> >>>>>>> 9.  Once the release branch is created(after code freeze), any bug
> >>>>>>> in jira can be marked with fix version current release(4.4) only on
> >>>>>>> RM's approval and only they can go to the release branch.  This
> can be
> >>>>>>> done through jira and with certain rules.(may be using jira vote?)
> >>>>>>> this would save the cherry-picking time and another branch
> >>> maintenance.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Ref:
> >>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>
> >>>>>>> ~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>*(tm)*
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> *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>*(tm)*
> >>>>
> >>>
> >>>
> >
>
>

Re: [DISCUSS][PROPOSAL] git workflow

[Abhinandan Prateek <Ab...@citrix.com>]

On 01/07/14 3:39 am, "Sebastien Goasguen" <ru...@gmail.com> wrote:

>I would like to re-start this discussion.
>
>Rajani made some good points and someone mentioned Gitflow:
>
>http://nvie.com/posts/a-successful-git-branching-model/
>
>Thinking about our release procedure, we clearly need more tests and a
>CI. However it looks like this is going to take some time.

At Citrix we are able to run CI with BVTs. The system of classification of
tests has enabled us to run around 70% of the BVTs on simulator. A single
cycle takes less than 3 hours to run. This can be further optimised. These
70% of the simulated tests can be run in dev environment[1]. There are two
things that community can do:

1. In short run for any feature commit, mandate that at least the
developers have run the simulator based tests before the merge request.
2. Get the required hardware and have a self service interface available
where devs can run the test on their feature branch.
3. Contribute test cases; now simulator also provides a way to check
failure scenarios [2]


[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins
+for+your+local+changes%2C+using+Simulator
[2] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Writing+tests+levera
ging+the+simulator+enhancements

-abhi

>
>In the meantime I think there is nothing preventing us from agreeing to
>'git practices', we don't need tests or new infra, we just need to agree
>on the git workflow.
>
>Right now Master is really a development branch, we should make it a
>stable branch for production with very few commits.
>This does not mean that we would release less, in contrary this would
>ensure that a commit to master means it's a production release.
>
>In addition gitflow [1] does not do cherry-picks (gets back to Rajani's
>point) everything is based on merges.
>
>I am of the opinion that git flow provides a nice process. It basically
>freezes master. Development happens in a 'develop' branch, releases
>branches are branched off of that and merged into master and back into
>develop�.etc
>
>Please read [1] it's a good read.
>
>And let's discuss,
>
>[1] http://nvie.com/posts/a-successful-git-branching-model/
>
>-Sebastien
>
>On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Ra...@citrix.com>
>wrote:
>
>> There is also the problem of cherry-picking.
>> As a contributor, I always endup creating multiple patches for each
>>branch as they don�t cleanly apply on the upward branches. which means
>>distinct commits for each branch and I don�t easily know which all
>>branches my commit exists unless I do grep.
>> if we follow merging strategy properly, apart from the first merge of
>>the branch, everything else on top of it should be a painless merge.
>> 
>> 
>> 
>> ~Rajani
>> 
>> 
>> 
>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
>> 
>>> I think many of the bullet points are what we are currently doing
>>> (guidelines for commit comments, feature branches need to stay in sync
>>>with
>>> master, no back-merging). I also think that much of what we do now is
>>>done
>>> the way it is simply because there *are* vast changes between versions.
>>> Classes are getting shuffled around and changed all the time. If its
>>> feasible to merge branch fixes to master, that's fine, but some quick
>>>tests
>>> seem to indicate that this will be messy getting started.
>>> 
>>> That leaves us with how we do releases. I'm fine with having single
>>> branches for major releases(4.3) and tagging the commits where each
>>> incremental release (4.3.x) is done. I'm trying to remember why we went
>>> with the -forward, I'm sure it's in the mailing list somewhere, but
>>>one of
>>> the nice things it provides is the ability for the release manager to
>>> control what changes are made during code freeze while giving people a
>>> place to stage fixes (though admittedly this is not always followed).
>>> Without -forward, would the flow be for each dev to have their own
>>>repo and
>>> issue pull requests for bugfixes?
>>> 
>>> 
>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi
>>><Ra...@citrix.com>
>>> wrote:
>>> 
>>>> Any other suggestions/objections/comments??
>>>> Can we discuss this in detail and agree to a process??
>>>> 
>>>> 
>>>> ~Rajani
>>>> 
>>>> 
>>>> 
>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi
>>>><Ra...@citrix.com>
>>>> wrote:
>>>> 
>>>>> Yes as mike said, if its a one-off case we can do a empty
>>>>>merge(merge -s
>>>> ours) for it and git will assume its merged but will not bring in any
>>>> changes.
>>>>> 
>>>>> If the branches diverged a lot, for example after a major rewrite, we
>>>> could stop merging to that branch and above and make the fix manually.
>>>>> 
>>>>> 
>>>>> ~Rajani
>>>>> 
>>>>> 
>>>>> 
>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>> mike.tutkowski@solidfire.com> wrote:
>>>>> 
>>>>>> Yep, that's what I was referring to in that a particular fix for an
>>>>>>old
>>>>>> release may not apply to newer versions. That does happen.
>>>>>> 
>>>>>> We used to mark those as "don't need to merge to branch x" in SVN
>>>>>>and
>>>> then
>>>>>> you handed it however made sense on the applicable branch(es).
>>>>>> 
>>>>>> 
>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>> Stephen.Turner@citrix.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> What happens if a fix isn't relevant for newer versions, or has to
>>>>>>>be
>>>>>>> rewritten for newer versions because the code has changed? Don't
>>>>>>>the
>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>> 
>>>>>>> --
>>>>>>> Stephen Turner
>>>>>>> 
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>> Sent: 30 May 2014 18:48
>>>>>>> To: dev@cloudstack.apache.org
>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>> 
>>>>>>> I think this flow is something we should seriously consider.
>>>>>>> 
>>>>>>> I find cherry picking from branch to branch to be error prone in
>>>>>>>that
>>>> it's
>>>>>>> easy for someone to forget to cherry pick to all applicable
>>>>>>>branches
>>>> and
>>>>>>> you don't have any easy way to see the cherry picks are related.
>>>>>>> 
>>>>>>> When I worked at HP, we had automated tools check to see if you
>>>> checked a
>>>>>>> fix into a prior release, but not later releases. In such a
>>>>>>>situation,
>>>> you
>>>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
>>>> longer
>>>>>>> applicable in the later release(s), so you needed to mark it as
>>>>>>> un-necessary (SVN supported this ability...not sure about Git).
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Our current git workflow is confusing with the *forward branches
>>>>>>>>and
>>>>>>>> cherry-picking. Its hard to track on what all releases the commit
>>>>>>>>has
>>>>>>>> gone into unless I do some git log greping. Also, as a
>>>>>>>>contributor, I
>>>>>>>> endup creating patches for each branch as it doesn�t cleanly
>>>>>>>>apply on
>>>>>>>> different branches.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I think we should have some guidelines. Here is what I propose.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
>>>>>>>>4.4.x,
>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly
>>>>>>>>on
>>>>>>>> the respective branches.
>>>>>>>> 2.  The branch naming convention is to be followed. Many branches
>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
>>>>>>>> we have two physically distinct commits for the same change or
>>>>>>>>fix and
>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>> 4.  There should always be a continous flow from release branches
>>>>>>>>to
>>>>>>>> master. This doesn�t mean cherry-picking. They should be
>>>>>>>>merged(either
>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable
>>>>>>>>with
>>>>>>>> git branch --contains
>>>>>>>>  *   Every bug fix should always flow from minimal release uptill
>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>  *   For ex. A bug 4.2.1 should be committed to
>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>  *   If someone forgets to do the merge, the next time a new
>>>>>>>>commit
>>>>>>> is
>>>>>>>> done this will also get merged.
>>>>>>>> 5.  There should always be a continuous flow from master to
>>>>>>>>feature
>>>>>>>> branches. Meaning all feature branch owners should proactively
>>>>>>>>take
>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>> 6.  The commits from feature branch will make to master on code
>>>>>>>> complete through a merge.
>>>>>>>> 7.  There should never be a merge from master to release branches
>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>>>>>>>> should have atleast bug id and correct author information
>>>>>>>>  *   Cassandra's template: patch by <author>; reviewed by
>>>> <committer>
>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>> 9.  Once the release branch is created(after code freeze), any bug
>>>>>>>> in jira can be marked with fix version current release(4.4) only
>>>>>>>>on
>>>>>>>> RM's approval and only they can go to the release branch.  This
>>>>>>>>can be
>>>>>>>> done through jira and with certain rules.(may be using jira vote?)
>>>>>>>> this would save the cherry-picking time and another branch
>>>> maintenance.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Ref:
>>>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>> 
>>>>>>>> ~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>*�*
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> *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: [DISCUSS][PROPOSAL] git workflow

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

On Jul 8, 2014, at 2:20 PM, Nate Gordon <na...@appcore.com> wrote:

> As someone who has worked with a number of different version control
> systems (and have far more love for git than any other), I'm curious as to
> why we would want to fight what I've always seen as the core feature of
> git. Branching and merging. The gitflow model is incredibly useful for
> keeping track of a number of different development paths concurrently.
> Branches remained organized and have a clear destination and workflow that
> they need to go through as part of the merging process. We use it
> internally (on a much smaller team) with great success. And with the
> difficulties I've seen on the mailing list around the -forward branches and
> cherry-picking,I'm curious as to why this is the preferred method.

I don't think it's the preferred method.
I see it as 'the method currently used'.

I think we need to change.

> From
> everything I've read about git and cherry-picking, it is a copy of the
> commit, not a reference to the original commit. This makes it hard to track
> down an individual change to find the original source.
> 
> Thanks,
> 
> -Nate
> 
> 
> On Tue, Jul 8, 2014 at 11:04 AM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
> 
>> Thanks for bringing this up again, Sebastien.
>> 
>> I've had http://nvie.com/posts/a-successful-git-branching-model/ up in
>> Chrome since you sent that link and been reading through it a bit here and
>> there, but have just been too busy as of late to give it a bunch of
>> thought.
>> 
>> I agree, though, that we should really think about moving to another model
>> of using Git as it is not un-common for master to be broken, which leads to
>> a lot of lost development time for many people.
>> 
>> 
>> On Mon, Jun 30, 2014 at 4:09 PM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>> 
>>> I would like to re-start this discussion.
>>> 
>>> Rajani made some good points and someone mentioned Gitflow:
>>> 
>>> http://nvie.com/posts/a-successful-git-branching-model/
>>> 
>>> Thinking about our release procedure, we clearly need more tests and a
>> CI.
>>> However it looks like this is going to take some time.
>>> 
>>> In the meantime I think there is nothing preventing us from agreeing to
>>> 'git practices', we don't need tests or new infra, we just need to agree
>> on
>>> the git workflow.
>>> 
>>> Right now Master is really a development branch, we should make it a
>>> stable branch for production with very few commits.
>>> This does not mean that we would release less, in contrary this would
>>> ensure that a commit to master means it's a production release.
>>> 
>>> In addition gitflow [1] does not do cherry-picks (gets back to Rajani's
>>> point) everything is based on merges.
>>> 
>>> I am of the opinion that git flow provides a nice process. It basically
>>> freezes master. Development happens in a 'develop' branch, releases
>>> branches are branched off of that and merged into master and back into
>>> develop….etc
>>> 
>>> Please read [1] it's a good read.
>>> 
>>> And let's discuss,
>>> 
>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>> 
>>> -Sebastien
>>> 
>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Rajani.Karuturi@citrix.com
>>> 
>>> wrote:
>>> 
>>>> There is also the problem of cherry-picking.
>>>> As a contributor, I always endup creating multiple patches for each
>>> branch as they don’t cleanly apply on the upward branches. which means
>>> distinct commits for each branch and I don’t easily know which all
>> branches
>>> my commit exists unless I do grep.
>>>> if we follow merging strategy properly, apart from the first merge of
>>> the branch, everything else on top of it should be a painless merge.
>>>> 
>>>> 
>>>> 
>>>> ~Rajani
>>>> 
>>>> 
>>>> 
>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
>>>> 
>>>>> I think many of the bullet points are what we are currently doing
>>>>> (guidelines for commit comments, feature branches need to stay in sync
>>> with
>>>>> master, no back-merging). I also think that much of what we do now is
>>> done
>>>>> the way it is simply because there *are* vast changes between
>> versions.
>>>>> Classes are getting shuffled around and changed all the time. If its
>>>>> feasible to merge branch fixes to master, that's fine, but some quick
>>> tests
>>>>> seem to indicate that this will be messy getting started.
>>>>> 
>>>>> That leaves us with how we do releases. I'm fine with having single
>>>>> branches for major releases(4.3) and tagging the commits where each
>>>>> incremental release (4.3.x) is done. I'm trying to remember why we
>> went
>>>>> with the -forward, I'm sure it's in the mailing list somewhere, but
>> one
>>> of
>>>>> the nice things it provides is the ability for the release manager to
>>>>> control what changes are made during code freeze while giving people a
>>>>> place to stage fixes (though admittedly this is not always followed).
>>>>> Without -forward, would the flow be for each dev to have their own
>> repo
>>> and
>>>>> issue pull requests for bugfixes?
>>>>> 
>>>>> 
>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>> Rajani.Karuturi@citrix.com>
>>>>> wrote:
>>>>> 
>>>>>> Any other suggestions/objections/comments??
>>>>>> Can we discuss this in detail and agree to a process??
>>>>>> 
>>>>>> 
>>>>>> ~Rajani
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>> Rajani.Karuturi@citrix.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>> merge(merge
>>> -s
>>>>>> ours) for it and git will assume its merged but will not bring in any
>>>>>> changes.
>>>>>>> 
>>>>>>> If the branches diverged a lot, for example after a major rewrite,
>> we
>>>>>> could stop merging to that branch and above and make the fix
>> manually.
>>>>>>> 
>>>>>>> 
>>>>>>> ~Rajani
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>> 
>>>>>>>> Yep, that's what I was referring to in that a particular fix for an
>>> old
>>>>>>>> release may not apply to newer versions. That does happen.
>>>>>>>> 
>>>>>>>> We used to mark those as "don't need to merge to branch x" in SVN
>> and
>>>>>> then
>>>>>>>> you handed it however made sense on the applicable branch(es).
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>> Stephen.Turner@citrix.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> What happens if a fix isn't relevant for newer versions, or has to
>>> be
>>>>>>>>> rewritten for newer versions because the code has changed? Don't
>> the
>>>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Stephen Turner
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>> 
>>>>>>>>> I think this flow is something we should seriously consider.
>>>>>>>>> 
>>>>>>>>> I find cherry picking from branch to branch to be error prone in
>>> that
>>>>>> it's
>>>>>>>>> easy for someone to forget to cherry pick to all applicable
>> branches
>>>>>> and
>>>>>>>>> you don't have any easy way to see the cherry picks are related.
>>>>>>>>> 
>>>>>>>>> When I worked at HP, we had automated tools check to see if you
>>>>>> checked a
>>>>>>>>> fix into a prior release, but not later releases. In such a
>>> situation,
>>>>>> you
>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
>>>>>> longer
>>>>>>>>> applicable in the later release(s), so you needed to mark it as
>>>>>>>>> un-necessary (SVN supported this ability...not sure about Git).
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>> 
>>>>>>>>>> Hi all,
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Our current git workflow is confusing with the *forward branches
>>> and
>>>>>>>>>> cherry-picking. Its hard to track on what all releases the commit
>>> has
>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>>> contributor, I
>>>>>>>>>> endup creating patches for each branch as it doesn’t cleanly
>> apply
>>> on
>>>>>>>>>> different branches.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I think we should have some guidelines. Here is what I propose.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
>>> 4.4.x,
>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly
>> on
>>>>>>>>>> the respective branches.
>>>>>>>>>> 2.  The branch naming convention is to be followed. Many branches
>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
>> cherry-pick,
>>>>>>>>>> we have two physically distinct commits for the same change or
>> fix
>>> and
>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>> 4.  There should always be a continous flow from release branches
>>> to
>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
>>> merged(either
>>>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable
>> with
>>>>>>>>>> git branch --contains
>>>>>>>>>> *   Every bug fix should always flow from minimal release uptill
>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>> *   If someone forgets to do the merge, the next time a new
>> commit
>>>>>>>>> is
>>>>>>>>>> done this will also get merged.
>>>>>>>>>> 5.  There should always be a continuous flow from master to
>> feature
>>>>>>>>>> branches. Meaning all feature branch owners should proactively
>> take
>>>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>>>> 6.  The commits from feature branch will make to master on code
>>>>>>>>>> complete through a merge.
>>>>>>>>>> 7.  There should never be a merge from master to release branches
>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>>>>>>>>>> should have atleast bug id and correct author information
>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>>>>>> <committer>
>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>> 9.  Once the release branch is created(after code freeze), any
>> bug
>>>>>>>>>> in jira can be marked with fix version current release(4.4) only
>> on
>>>>>>>>>> RM's approval and only they can go to the release branch.  This
>>> can be
>>>>>>>>>> done through jira and with certain rules.(may be using jira
>> vote?)
>>>>>>>>>> this would save the cherry-picking time and another branch
>>>>>> maintenance.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Ref:
>>>>>>>>>> 
>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>> 
>>>>>>>>>> ~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>*™*
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> *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>*™*
>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> --
>> *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>*™*
>> 
> 
> 
> 
> -- 
> 
> 
> *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: [DISCUSS][PROPOSAL] git workflow

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

As someone who has worked with a number of different version control
systems (and have far more love for git than any other), I'm curious as to
why we would want to fight what I've always seen as the core feature of
git. Branching and merging. The gitflow model is incredibly useful for
keeping track of a number of different development paths concurrently.
Branches remained organized and have a clear destination and workflow that
they need to go through as part of the merging process. We use it
internally (on a much smaller team) with great success. And with the
difficulties I've seen on the mailing list around the -forward branches and
cherry-picking, I'm curious as to why this is the preferred method. From
everything I've read about git and cherry-picking, it is a copy of the
commit, not a reference to the original commit. This makes it hard to track
down an individual change to find the original source.

Thanks,

-Nate


On Tue, Jul 8, 2014 at 11:04 AM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Thanks for bringing this up again, Sebastien.
>
> I've had http://nvie.com/posts/a-successful-git-branching-model/ up in
> Chrome since you sent that link and been reading through it a bit here and
> there, but have just been too busy as of late to give it a bunch of
> thought.
>
> I agree, though, that we should really think about moving to another model
> of using Git as it is not un-common for master to be broken, which leads to
> a lot of lost development time for many people.
>
>
> On Mon, Jun 30, 2014 at 4:09 PM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
>
> > I would like to re-start this discussion.
> >
> > Rajani made some good points and someone mentioned Gitflow:
> >
> > http://nvie.com/posts/a-successful-git-branching-model/
> >
> > Thinking about our release procedure, we clearly need more tests and a
> CI.
> > However it looks like this is going to take some time.
> >
> > In the meantime I think there is nothing preventing us from agreeing to
> > 'git practices', we don't need tests or new infra, we just need to agree
> on
> > the git workflow.
> >
> > Right now Master is really a development branch, we should make it a
> > stable branch for production with very few commits.
> > This does not mean that we would release less, in contrary this would
> > ensure that a commit to master means it's a production release.
> >
> > In addition gitflow [1] does not do cherry-picks (gets back to Rajani's
> > point) everything is based on merges.
> >
> > I am of the opinion that git flow provides a nice process. It basically
> > freezes master. Development happens in a 'develop' branch, releases
> > branches are branched off of that and merged into master and back into
> > develop….etc
> >
> > Please read [1] it's a good read.
> >
> > And let's discuss,
> >
> > [1] http://nvie.com/posts/a-successful-git-branching-model/
> >
> > -Sebastien
> >
> > On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Rajani.Karuturi@citrix.com
> >
> > wrote:
> >
> > > There is also the problem of cherry-picking.
> > > As a contributor, I always endup creating multiple patches for each
> > branch as they don’t cleanly apply on the upward branches. which means
> > distinct commits for each branch and I don’t easily know which all
> branches
> > my commit exists unless I do grep.
> > > if we follow merging strategy properly, apart from the first merge of
> > the branch, everything else on top of it should be a painless merge.
> > >
> > >
> > >
> > > ~Rajani
> > >
> > >
> > >
> > > On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
> > >
> > >> I think many of the bullet points are what we are currently doing
> > >> (guidelines for commit comments, feature branches need to stay in sync
> > with
> > >> master, no back-merging). I also think that much of what we do now is
> > done
> > >> the way it is simply because there *are* vast changes between
> versions.
> > >> Classes are getting shuffled around and changed all the time. If its
> > >> feasible to merge branch fixes to master, that's fine, but some quick
> > tests
> > >> seem to indicate that this will be messy getting started.
> > >>
> > >> That leaves us with how we do releases. I'm fine with having single
> > >> branches for major releases(4.3) and tagging the commits where each
> > >> incremental release (4.3.x) is done. I'm trying to remember why we
> went
> > >> with the -forward, I'm sure it's in the mailing list somewhere, but
> one
> > of
> > >> the nice things it provides is the ability for the release manager to
> > >> control what changes are made during code freeze while giving people a
> > >> place to stage fixes (though admittedly this is not always followed).
> > >> Without -forward, would the flow be for each dev to have their own
> repo
> > and
> > >> issue pull requests for bugfixes?
> > >>
> > >>
> > >> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> > Rajani.Karuturi@citrix.com>
> > >> wrote:
> > >>
> > >>> Any other suggestions/objections/comments??
> > >>> Can we discuss this in detail and agree to a process??
> > >>>
> > >>>
> > >>> ~Rajani
> > >>>
> > >>>
> > >>>
> > >>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> > Rajani.Karuturi@citrix.com>
> > >>> wrote:
> > >>>
> > >>>> Yes as mike said, if its a one-off case we can do a empty
> merge(merge
> > -s
> > >>> ours) for it and git will assume its merged but will not bring in any
> > >>> changes.
> > >>>>
> > >>>> If the branches diverged a lot, for example after a major rewrite,
> we
> > >>> could stop merging to that branch and above and make the fix
> manually.
> > >>>>
> > >>>>
> > >>>> ~Rajani
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> > >>> mike.tutkowski@solidfire.com> wrote:
> > >>>>
> > >>>>> Yep, that's what I was referring to in that a particular fix for an
> > old
> > >>>>> release may not apply to newer versions. That does happen.
> > >>>>>
> > >>>>> We used to mark those as "don't need to merge to branch x" in SVN
> and
> > >>> then
> > >>>>> you handed it however made sense on the applicable branch(es).
> > >>>>>
> > >>>>>
> > >>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> > >>> Stephen.Turner@citrix.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> What happens if a fix isn't relevant for newer versions, or has to
> > be
> > >>>>>> rewritten for newer versions because the code has changed? Don't
> the
> > >>>>>> branches diverge and you end up cherry-picking after that?
> > >>>>>>
> > >>>>>> --
> > >>>>>> Stephen Turner
> > >>>>>>
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> > >>>>>> Sent: 30 May 2014 18:48
> > >>>>>> To: dev@cloudstack.apache.org
> > >>>>>> Subject: Re: [PROPOSAL] git workflow
> > >>>>>>
> > >>>>>> I think this flow is something we should seriously consider.
> > >>>>>>
> > >>>>>> I find cherry picking from branch to branch to be error prone in
> > that
> > >>> it's
> > >>>>>> easy for someone to forget to cherry pick to all applicable
> branches
> > >>> and
> > >>>>>> you don't have any easy way to see the cherry picks are related.
> > >>>>>>
> > >>>>>> When I worked at HP, we had automated tools check to see if you
> > >>> checked a
> > >>>>>> fix into a prior release, but not later releases. In such a
> > situation,
> > >>> you
> > >>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
> > >>> longer
> > >>>>>> applicable in the later release(s), so you needed to mark it as
> > >>>>>> un-necessary (SVN supported this ability...not sure about Git).
> > >>>>>>
> > >>>>>>
> > >>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> > >>>>>> Rajani.Karuturi@citrix.com> wrote:
> > >>>>>>
> > >>>>>>> Hi all,
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Our current git workflow is confusing with the *forward branches
> > and
> > >>>>>>> cherry-picking. Its hard to track on what all releases the commit
> > has
> > >>>>>>> gone into unless I do some git log greping. Also, as a
> > contributor, I
> > >>>>>>> endup creating patches for each branch as it doesn’t cleanly
> apply
> > on
> > >>>>>>> different branches.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> I think we should have some guidelines. Here is what I propose.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
> > 4.4.x,
> > >>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly
> on
> > >>>>>>> the respective branches.
> > >>>>>>> 2.  The branch naming convention is to be followed. Many branches
> > >>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> > >>>>>>> 3.  Cherry-picking should be avoided. In git, when we
> cherry-pick,
> > >>>>>>> we have two physically distinct commits for the same change or
> fix
> > and
> > >>>>>>> is difficult to track unless you do cherry-pick -x
> > >>>>>>> 4.  There should always be a continous flow from release branches
> > to
> > >>>>>>> master. This doesn’t mean cherry-picking. They should be
> > merged(either
> > >>>>>>> ff or no-ff) which retains the commit ids and easily trackable
> with
> > >>>>>>> git branch --contains
> > >>>>>>>  *   Every bug fix should always flow from minimal release uptill
> > >>>>>>> master. A bug isnt fixed until the fix reaches master.
> > >>>>>>>  *   For ex. A bug 4.2.1 should be committed to
> > >>>>>>> 4.2.x->4.3.x->4.4.x->master
> > >>>>>>>  *   If someone forgets to do the merge, the next time a new
> commit
> > >>>>>> is
> > >>>>>>> done this will also get merged.
> > >>>>>>> 5.  There should always be a continuous flow from master to
> feature
> > >>>>>>> branches. Meaning all feature branch owners should proactively
> take
> > >>>>>>> any new commits from master by doing a merge from master
> > >>>>>>> 6.  The commits from feature branch will make to master on code
> > >>>>>>> complete through a merge.
> > >>>>>>> 7.  There should never be a merge from master to release branches
> > >>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
> > >>>>>>> should have atleast bug id and correct author information
> > >>>>>>>  *   Cassandra's template: patch by <author>; reviewed by
> > >>> <committer>
> > >>>>>>> for CASSANDRA-<ticket>
> > >>>>>>> 9.  Once the release branch is created(after code freeze), any
> bug
> > >>>>>>> in jira can be marked with fix version current release(4.4) only
> on
> > >>>>>>> RM's approval and only they can go to the release branch.  This
> > can be
> > >>>>>>> done through jira and with certain rules.(may be using jira
> vote?)
> > >>>>>>> this would save the cherry-picking time and another branch
> > >>> maintenance.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Please add your thoughts/suggestions/comments.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Ref:
> > >>>>>>>
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> > >>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> > >>>>>>>
> > >>>>>>> ~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>*™*
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> *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>*™*
> > >>>>
> > >>>
> > >>>
> > >
> >
> >
>
>
> --
> *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>*™*
>



-- 


*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: [DISCUSS][PROPOSAL] git workflow

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

Thanks for bringing this up again, Sebastien.

I've had http://nvie.com/posts/a-successful-git-branching-model/ up in
Chrome since you sent that link and been reading through it a bit here and
there, but have just been too busy as of late to give it a bunch of thought.

I agree, though, that we should really think about moving to another model
of using Git as it is not un-common for master to be broken, which leads to
a lot of lost development time for many people.


On Mon, Jun 30, 2014 at 4:09 PM, Sebastien Goasguen <ru...@gmail.com>
wrote:

> I would like to re-start this discussion.
>
> Rajani made some good points and someone mentioned Gitflow:
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> Thinking about our release procedure, we clearly need more tests and a CI.
> However it looks like this is going to take some time.
>
> In the meantime I think there is nothing preventing us from agreeing to
> 'git practices', we don't need tests or new infra, we just need to agree on
> the git workflow.
>
> Right now Master is really a development branch, we should make it a
> stable branch for production with very few commits.
> This does not mean that we would release less, in contrary this would
> ensure that a commit to master means it's a production release.
>
> In addition gitflow [1] does not do cherry-picks (gets back to Rajani's
> point) everything is based on merges.
>
> I am of the opinion that git flow provides a nice process. It basically
> freezes master. Development happens in a 'develop' branch, releases
> branches are branched off of that and merged into master and back into
> develop….etc
>
> Please read [1] it's a good read.
>
> And let's discuss,
>
> [1] http://nvie.com/posts/a-successful-git-branching-model/
>
> -Sebastien
>
> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Ra...@citrix.com>
> wrote:
>
> > There is also the problem of cherry-picking.
> > As a contributor, I always endup creating multiple patches for each
> branch as they don’t cleanly apply on the upward branches. which means
> distinct commits for each branch and I don’t easily know which all branches
> my commit exists unless I do grep.
> > if we follow merging strategy properly, apart from the first merge of
> the branch, everything else on top of it should be a painless merge.
> >
> >
> >
> > ~Rajani
> >
> >
> >
> > On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
> >
> >> I think many of the bullet points are what we are currently doing
> >> (guidelines for commit comments, feature branches need to stay in sync
> with
> >> master, no back-merging). I also think that much of what we do now is
> done
> >> the way it is simply because there *are* vast changes between versions.
> >> Classes are getting shuffled around and changed all the time. If its
> >> feasible to merge branch fixes to master, that's fine, but some quick
> tests
> >> seem to indicate that this will be messy getting started.
> >>
> >> That leaves us with how we do releases. I'm fine with having single
> >> branches for major releases(4.3) and tagging the commits where each
> >> incremental release (4.3.x) is done. I'm trying to remember why we went
> >> with the -forward, I'm sure it's in the mailing list somewhere, but one
> of
> >> the nice things it provides is the ability for the release manager to
> >> control what changes are made during code freeze while giving people a
> >> place to stage fixes (though admittedly this is not always followed).
> >> Without -forward, would the flow be for each dev to have their own repo
> and
> >> issue pull requests for bugfixes?
> >>
> >>
> >> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> Rajani.Karuturi@citrix.com>
> >> wrote:
> >>
> >>> Any other suggestions/objections/comments??
> >>> Can we discuss this in detail and agree to a process??
> >>>
> >>>
> >>> ~Rajani
> >>>
> >>>
> >>>
> >>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> Rajani.Karuturi@citrix.com>
> >>> wrote:
> >>>
> >>>> Yes as mike said, if its a one-off case we can do a empty merge(merge
> -s
> >>> ours) for it and git will assume its merged but will not bring in any
> >>> changes.
> >>>>
> >>>> If the branches diverged a lot, for example after a major rewrite, we
> >>> could stop merging to that branch and above and make the fix manually.
> >>>>
> >>>>
> >>>> ~Rajani
> >>>>
> >>>>
> >>>>
> >>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>> mike.tutkowski@solidfire.com> wrote:
> >>>>
> >>>>> Yep, that's what I was referring to in that a particular fix for an
> old
> >>>>> release may not apply to newer versions. That does happen.
> >>>>>
> >>>>> We used to mark those as "don't need to merge to branch x" in SVN and
> >>> then
> >>>>> you handed it however made sense on the applicable branch(es).
> >>>>>
> >>>>>
> >>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>> Stephen.Turner@citrix.com>
> >>>>> wrote:
> >>>>>
> >>>>>> What happens if a fix isn't relevant for newer versions, or has to
> be
> >>>>>> rewritten for newer versions because the code has changed? Don't the
> >>>>>> branches diverge and you end up cherry-picking after that?
> >>>>>>
> >>>>>> --
> >>>>>> Stephen Turner
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> >>>>>> Sent: 30 May 2014 18:48
> >>>>>> To: dev@cloudstack.apache.org
> >>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>
> >>>>>> I think this flow is something we should seriously consider.
> >>>>>>
> >>>>>> I find cherry picking from branch to branch to be error prone in
> that
> >>> it's
> >>>>>> easy for someone to forget to cherry pick to all applicable branches
> >>> and
> >>>>>> you don't have any easy way to see the cherry picks are related.
> >>>>>>
> >>>>>> When I worked at HP, we had automated tools check to see if you
> >>> checked a
> >>>>>> fix into a prior release, but not later releases. In such a
> situation,
> >>> you
> >>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
> >>> longer
> >>>>>> applicable in the later release(s), so you needed to mark it as
> >>>>>> un-necessary (SVN supported this ability...not sure about Git).
> >>>>>>
> >>>>>>
> >>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Our current git workflow is confusing with the *forward branches
> and
> >>>>>>> cherry-picking. Its hard to track on what all releases the commit
> has
> >>>>>>> gone into unless I do some git log greping. Also, as a
> contributor, I
> >>>>>>> endup creating patches for each branch as it doesn’t cleanly apply
> on
> >>>>>>> different branches.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> I think we should have some guidelines. Here is what I propose.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
> 4.4.x,
> >>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on
> >>>>>>> the respective branches.
> >>>>>>> 2.  The branch naming convention is to be followed. Many branches
> >>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
> >>>>>>> we have two physically distinct commits for the same change or fix
> and
> >>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>> 4.  There should always be a continous flow from release branches
> to
> >>>>>>> master. This doesn’t mean cherry-picking. They should be
> merged(either
> >>>>>>> ff or no-ff) which retains the commit ids and easily trackable with
> >>>>>>> git branch --contains
> >>>>>>>  *   Every bug fix should always flow from minimal release uptill
> >>>>>>> master. A bug isnt fixed until the fix reaches master.
> >>>>>>>  *   For ex. A bug 4.2.1 should be committed to
> >>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>  *   If someone forgets to do the merge, the next time a new commit
> >>>>>> is
> >>>>>>> done this will also get merged.
> >>>>>>> 5.  There should always be a continuous flow from master to feature
> >>>>>>> branches. Meaning all feature branch owners should proactively take
> >>>>>>> any new commits from master by doing a merge from master
> >>>>>>> 6.  The commits from feature branch will make to master on code
> >>>>>>> complete through a merge.
> >>>>>>> 7.  There should never be a merge from master to release branches
> >>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
> >>>>>>> should have atleast bug id and correct author information
> >>>>>>>  *   Cassandra's template: patch by <author>; reviewed by
> >>> <committer>
> >>>>>>> for CASSANDRA-<ticket>
> >>>>>>> 9.  Once the release branch is created(after code freeze), any bug
> >>>>>>> in jira can be marked with fix version current release(4.4) only on
> >>>>>>> RM's approval and only they can go to the release branch.  This
> can be
> >>>>>>> done through jira and with certain rules.(may be using jira vote?)
> >>>>>>> this would save the cherry-picking time and another branch
> >>> maintenance.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Ref:
> >>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>
> >>>>>>> ~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>*™*
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> *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>*™*
> >>>>
> >>>
> >>>
> >
>
>


-- 
*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: [DISCUSS][PROPOSAL] git workflow

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

Right, 'master' should - theoretically - be somewhat stable at present as
we are post 4.5 Feature Freeze.

I guess we should address Daan's question of what 'develop' means in this
new model? When can code be checked into 'develop', but not 'master'? Code
that goes into 'master' must be deemed 'stable.' What about 'develop'? Why
do we have it if we're using our own branches for development?

Thanks for clarifying.


On Wed, Jul 23, 2014 at 11:01 AM, Erik Weber <te...@gmail.com> wrote:

> Must it start today, or when (if) the vote passes? Feature freeze for 4.5
> has theoretically passed, so basically master branch should now be work in
> progress towards a stable branch.
>
> So I'd say; create a 'develop' branch off the current master.
>
> Keep master as is, and only merge bugfixes until it is deemed stable and
> 4.5 is released.
>
> 4.6 development and new features goes into branches of 'develop'.
>
> Erik
> 23. juli 2014 18:30 skrev "Sebastien Goasguen" <ru...@gmail.com>
> følgende:
>
> >
> > On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com>
> wrote:
> >
> > > Let me ask the question, why have master be develop and a release
> branch
> > be
> > > "master"? If we are going to follow gitflow, why not just stick with
> the
> > > norm? If master is the development branch, it might not be stable. I
> > think
> > > the goal here is that we have an obvious stable branch. Anyone could
> come
> > > check out master and have the latest useable.
> >
> > I am in favor of following the norm, so ideally master should be our
> > stable branch (agreed).
> >
> > The issue is with the transition.
> >
> > Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally
> we
> > could start a stable branch of this tag and build up bug fix releases all
> > the way to 4.5 from there.
> >
> > But all features for 4.5 are already in master.
> >
> > So if we create a 'develop' branch of master and stabilize 'master' then
> > develop is now started from a stable tag (4.4.0).
> >
> > So what's the best way to flip ? There is most likely some git magic that
> > can we do.
> >
> >
> > The new git workflow and the transition process need to be part of a
> > proposal that we get consensus on.
> >
> > getting there :)
> >
> > -seb
> >
> > >
> > > Also, I'm struggling to understand the benefit of cherry-pick. If you
> > > completely squash history, you lose a tremendous amount of context,
> > which I
> > > use extensively to figure out why a bug is the way it is. Only knowing
> > that
> > > the branch was merged at a given point in time doesn't give any
> context.
> > > Seeing the individual commit history of the branch helps to preserve
> the
> > > rationale for why the code was written the way it was. In theory if
> every
> > > change starts out as a branch (feature, hotfix, release), then why not
> > just
> > > merge the branch once it is in a good and acceptable state?
> > >
> > > I also agree with Mike that this will have to be a transition over
> time.
> > It
> > > will take some time to clean up master to the point where it can be
> > > considered a solid stable branch. Possibly as part of the 4.5 release.
> > >
> > >
> > > On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <runseb@gmail.com
> >
> > > wrote:
> > >
> > >>
> > >> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
> > >> wrote:
> > >>
> > >>> Sebastien,
> > >>>
> > >>> It seems we can do what you are calling for is creating a branch
> > >>> called 'release'. We can merge back into that branch from 4.4,
> master,
> > >>> 4.3. I would like to see people that want a feature or bug fix in a
> > >>> branch make a fork of that branch and when that fork is working do a
> > >>> cherry-pick. The -forward concept is now used for that but it is
> > >>> broken because more then for one piece of work there are commits on
> > >>> it. This caused me conflicts during the release. Especially painfull
> > >>> as not all was intended to get into the release. We can create this
> > >>> 'release' branch now on the basis of 4.4 and start pulling in
> changes.
> > >>
> > >> Yes, that's what I am thinking about too, so +1
> > >>
> > >> Our master would become the -develop- in gitflow terms
> > >> The release branch you mention would become the -master- in gitflow
> > terms
> > >>
> > >> If we start now, indeed we can create 'release' from 4.4 release tag
> > >> (voted and shipped).
> > >>
> > >> That means that to create 4.5 we will need to merge features back into
> > >> 'release'. it might be messy because some of those features are
> already
> > in
> > >> our current master.
> > >>
> > >> But all of this will keep 'release' clean (we can keep track of bugs
> and
> > >> features that are in it in CHANGES file etc..)
> > >>
> > >>
> > >>> There is a question of control. Do we allow all committers to manage
> > >>> the release? I am for that but can imagine not everybody is.
> > >>>
> > >>
> > >> At first I would say that only the RM can commit to 'release'. As we
> get
> > >> the CI in place  we could relax this and allow commits that pass the
> CI
> > to
> > >> get into 'release', but right now I would vote for a tighter control
> of
> > >> 'release'.
> > >>
> > >>> rule number 1 will be: you are going to do something to the code, you
> > >>> start by creating a branch.
> > >>>
> > >>> right?
> > >>>
> > >>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
> runseb@gmail.com>
> > >> wrote:
> > >>>>
> > >>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
> > >> wrote:
> > >>>>
> > >>>>> Hey everyone,
> > >>>>>
> > >>>>> I've been a developer for a handful of years and have had my share
> of
> > >>>>> experience with different version control systems.  I've used (for
> > >> better
> > >>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> > >>>>>
> > >>>>> Each of these solutions offers their own unique set of features,
> > >> strengths
> > >>>>> and weaknesses.  As there are so many systems that are good at
> > specific
> > >>>>> things, it seems best to use the features that the chosen system is
> > >> best at.
> > >>>>>
> > >>>>> Git is great at branching, merging and using that structure to
> > >> maintain and
> > >>>>> control how changes get into the primary branches.  Git tools even
> > make
> > >>>>> this easy by integrating directly into the "Gitflow" to make
> > branching
> > >> and
> > >>>>> merging that much easier.  It would seem counter-intuitive to NOT
> > make
> > >> use
> > >>>>> of these built-in capabilities.
> > >>>>>
> > >>>>> In addition to that, I know that the current method of change
> > >> management is
> > >>>>> incredibly frustrating to work with, and works directly against the
> > >> way a
> > >>>>> typical Git user would expect it to be structured.  I should NEVER
> > have
> > >>>>> problem compiling and running something on master.  I should not
> have
> > >>>>> problems building anything on a release branch.  A feature/bugfix
> > >> branch is
> > >>>>> where things can be, and often are, broken or unstable.  There have
> > >> been
> > >>>>> many times working in Cloudstack where I've had to search for a
> > stable
> > >>>>> revision on master, and that's just plain wrong.
> > >>>>>
> > >>>>> I do realize that having this many developers working on so many
> > >> features
> > >>>>> and bugfixes will result in a large number of branches.  I don't
> > >> believe
> > >>>>> this is a good argument against using a branching method, though -
> I
> > >>>>> believe that the current system is even more confusing and
> difficult
> > >> to use.
> > >>>>>
> > >>>>> I could pontificate on change management quite a bit more, but my
> > >> opinion
> > >>>>> in summary would basically be:  use Git the way it was meant to be
> > >> used,
> > >>>>> and things will be better.  Just my two cents.
> > >>>>>
> > >>>>> Sam
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> Sam, I think we are in agreement (at least with folks who responded
> to
> > >> this thread).
> > >>>> Or maybe I am not reading your mail right and you don't agree with
> > Leo ?
> > >>>>
> > >>>> My own take and reason for calling for a change we are currently
> doing
> > >> things is mostly due to the way we release.
> > >>>>
> > >>>> I would like to see a stable master (and I think we are in agreement
> > >> with that).
> > >>>> That means that development should not happen on master and that
> every
> > >> commit that lands on master should be shippable.
> > >>>>
> > >>>> I personally have no issues with cherry-picking. So I would be fine
> > >> cherry picking from a hot-fix branch into master, to fix a bug.
> > >>>> The end result is that the next commit on master would still mean
> > >> master is shippable/releasable.
> > >>>>
> > >>>> If we agree with this basic concept. The question becomes how do we
> > get
> > >> there, considering that master is now full of dev work and potential
> > bug.
> > >>>> The only releasable product we have are on the 4.3, 4.4 and previous
> > >> release branches.
> > >>>>
> > >>>> Ideally, I would like to see master becomes 4.4. And work our way
> > back,
> > >> merging the new features that are already in master into the new
> master
> > >> (based on 4.4).
> > >>>> This could be quite complicated but we need to do it (or something
> > like
> > >> it).
> > >>>>
> > >>>> To move forward, we should make a proposal to the list and call for
> a
> > >> vote.
> > >>>>
> > >>>> Any takers to start a wiki page proposing a new git process and how
> we
> > >> could move to it (transition path) ?
> > >>>>
> > >>>>
> > >>>> -Sebastien
> > >>>>
> > >>>>
> > >>>>>
> > >>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
> > >> LSimons@schubergphilis.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Hey folks,
> > >>>>>>
> > >>>>>> With 4.4.0 tagged, is now an opportune time to go and implement
> > this?
> > >>>>>>
> > >>>>>> I would enthousiastically +1 and get crackin', but I’m not a
> > >> committer so
> > >>>>>> its not that practical for me to volunteer!
> > >>>>>>
> > >>>>>> I wanted to point out atlassian’s description of gitflow
> > >>>>>>
> > >>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
> > >>>>>>
> > >>>>>> which might be easier to read.
> > >>>>>>
> > >>>>>> Similarly, the git-flow scripts that help out with implementing
> this
> > >> stuff
> > >>>>>>
> > >>>>>> https://github.com/nvie/gitflow
> > >>>>>>
> > >>>>>> they also describe the relationship between gitflow and dealing
> with
> > >>>>>> multiple remotes
> > >>>>>>
> > >>>>>> https://www.atlassian.com/git/workflows#!pull-request
> > >>>>>>
> > >>>>>> Finally note atlassian’s free sourcetree GUI has built-in support
> > for
> > >>>>>> git-flow
> > >>>>>>
> > >>>>>> http://www.sourcetreeapp.com/
> > >>>>>>
> > >>>>>> Because cloudstack currently is full of rebasing and squashing and
> > >>>>>> cherry-picking, you get very little benefit from a tree
> > visualization
> > >> tool
> > >>>>>> (like this or gitk or ...) right now, but it would be *great* to
> > have
> > >> going
> > >>>>>> forward.
> > >>>>>>
> > >>>>>>
> > >>>>>> cheers,
> > >>>>>>
> > >>>>>>
> > >>>>>> Leo
> > >>>>>>
> > >>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <runseb@gmail.com
> >
> > >> wrote:
> > >>>>>>
> > >>>>>>> I would like to re-start this discussion.
> > >>>>>>>
> > >>>>>>> Rajani made some good points and someone mentioned Gitflow:
> > >>>>>>>
> > >>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
> > >>>>>>>
> > >>>>>>> Thinking about our release procedure, we clearly need more tests
> > and
> > >> a
> > >>>>>> CI. However it looks like this is going to take some time.
> > >>>>>>>
> > >>>>>>> In the meantime I think there is nothing preventing us from
> > agreeing
> > >> to
> > >>>>>> 'git practices', we don't need tests or new infra, we just need to
> > >> agree on
> > >>>>>> the git workflow.
> > >>>>>>>
> > >>>>>>> Right now Master is really a development branch, we should make
> it
> > a
> > >>>>>> stable branch for production with very few commits.
> > >>>>>>> This does not mean that we would release less, in contrary this
> > would
> > >>>>>> ensure that a commit to master means it's a production release.
> > >>>>>>>
> > >>>>>>> In addition gitflow [1] does not do cherry-picks (gets back to
> > >> Rajani's
> > >>>>>> point) everything is based on merges.
> > >>>>>>>
> > >>>>>>> I am of the opinion that git flow provides a nice process. It
> > >> basically
> > >>>>>> freezes master. Development happens in a 'develop' branch,
> releases
> > >>>>>> branches are branched off of that and merged into master and back
> > into
> > >>>>>> develop….etc
> > >>>>>>>
> > >>>>>>> Please read [1] it's a good read.
> > >>>>>>>
> > >>>>>>> And let's discuss,
> > >>>>>>>
> > >>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
> > >>>>>>>
> > >>>>>>> -Sebastien
> > >>>>>>>
> > >>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
> > >> Rajani.Karuturi@citrix.com>
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> There is also the problem of cherry-picking.
> > >>>>>>>> As a contributor, I always endup creating multiple patches for
> > each
> > >>>>>> branch as they don’t cleanly apply on the upward branches. which
> > means
> > >>>>>> distinct commits for each branch and I don’t easily know which all
> > >> branches
> > >>>>>> my commit exists unless I do grep.
> > >>>>>>>> if we follow merging strategy properly, apart from the first
> merge
> > >> of
> > >>>>>> the branch, everything else on top of it should be a painless
> merge.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> ~Rajani
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
> wrote:
> > >>>>>>>>
> > >>>>>>>>> I think many of the bullet points are what we are currently
> doing
> > >>>>>>>>> (guidelines for commit comments, feature branches need to stay
> in
> > >> sync
> > >>>>>> with
> > >>>>>>>>> master, no back-merging). I also think that much of what we do
> > now
> > >> is
> > >>>>>> done
> > >>>>>>>>> the way it is simply because there *are* vast changes between
> > >> versions.
> > >>>>>>>>> Classes are getting shuffled around and changed all the time.
> If
> > >> its
> > >>>>>>>>> feasible to merge branch fixes to master, that's fine, but some
> > >> quick
> > >>>>>> tests
> > >>>>>>>>> seem to indicate that this will be messy getting started.
> > >>>>>>>>>
> > >>>>>>>>> That leaves us with how we do releases. I'm fine with having
> > single
> > >>>>>>>>> branches for major releases(4.3) and tagging the commits where
> > each
> > >>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember why
> > we
> > >> went
> > >>>>>>>>> with the -forward, I'm sure it's in the mailing list somewhere,
> > but
> > >>>>>> one of
> > >>>>>>>>> the nice things it provides is the ability for the release
> > manager
> > >> to
> > >>>>>>>>> control what changes are made during code freeze while giving
> > >> people a
> > >>>>>>>>> place to stage fixes (though admittedly this is not always
> > >> followed).
> > >>>>>>>>> Without -forward, would the flow be for each dev to have their
> > own
> > >>>>>> repo and
> > >>>>>>>>> issue pull requests for bugfixes?
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> > >>>>>> Rajani.Karuturi@citrix.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Any other suggestions/objections/comments??
> > >>>>>>>>>> Can we discuss this in detail and agree to a process??
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> ~Rajani
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> > >>>>>> Rajani.Karuturi@citrix.com>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
> > >>>>>> merge(merge -s
> > >>>>>>>>>> ours) for it and git will assume its merged but will not bring
> > in
> > >> any
> > >>>>>>>>>> changes.
> > >>>>>>>>>>>
> > >>>>>>>>>>> If the branches diverged a lot, for example after a major
> > >> rewrite, we
> > >>>>>>>>>> could stop merging to that branch and above and make the fix
> > >> manually.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> ~Rajani
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> > >>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Yep, that's what I was referring to in that a particular fix
> > >> for an
> > >>>>>> old
> > >>>>>>>>>>>> release may not apply to newer versions. That does happen.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> We used to mark those as "don't need to merge to branch x"
> in
> > >> SVN
> > >>>>>> and
> > >>>>>>>>>> then
> > >>>>>>>>>>>> you handed it however made sense on the applicable
> branch(es).
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> > >>>>>>>>>> Stephen.Turner@citrix.com>
> > >>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
> > >> has to
> > >>>>>> be
> > >>>>>>>>>>>>> rewritten for newer versions because the code has changed?
> > >> Don't
> > >>>>>> the
> > >>>>>>>>>>>>> branches diverge and you end up cherry-picking after that?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> --
> > >>>>>>>>>>>>> Stephen Turner
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> -----Original Message-----
> > >>>>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> > >>>>>>>>>>>>> Sent: 30 May 2014 18:48
> > >>>>>>>>>>>>> To: dev@cloudstack.apache.org
> > >>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I think this flow is something we should seriously
> consider.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I find cherry picking from branch to branch to be error
> prone
> > >> in
> > >>>>>> that
> > >>>>>>>>>> it's
> > >>>>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
> > >>>>>> branches
> > >>>>>>>>>> and
> > >>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
> > >> related.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> When I worked at HP, we had automated tools check to see if
> > you
> > >>>>>>>>>> checked a
> > >>>>>>>>>>>>> fix into a prior release, but not later releases. In such a
> > >>>>>> situation,
> > >>>>>>>>>> you
> > >>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
> > >> was no
> > >>>>>>>>>> longer
> > >>>>>>>>>>>>> applicable in the later release(s), so you needed to mark
> it
> > as
> > >>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure about
> > Git).
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> > >>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Hi all,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Our current git workflow is confusing with the *forward
> > >> branches
> > >>>>>> and
> > >>>>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
> > >> commit
> > >>>>>> has
> > >>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
> > >>>>>> contributor, I
> > >>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
> cleanly
> > >>>>>> apply on
> > >>>>>>>>>>>>>> different branches.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
> > >> propose.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 1.  There should be branch for every major release(ex:
> > 4.3.x,
> > >>>>>> 4.4.x,
> > >>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
> > >> accordingly
> > >>>>>> on
> > >>>>>>>>>>>>>> the respective branches.
> > >>>>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
> > >> branches
> > >>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> > >>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
> > >> cherry-pick,
> > >>>>>>>>>>>>>> we have two physically distinct commits for the same
> change
> > or
> > >>>>>> fix and
> > >>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
> > >>>>>>>>>>>>>> 4.  There should always be a continous flow from release
> > >> branches
> > >>>>>> to
> > >>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
> > >>>>>> merged(either
> > >>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
> > trackable
> > >>>>>> with
> > >>>>>>>>>>>>>> git branch --contains
> > >>>>>>>>>>>>>> *   Every bug fix should always flow from minimal release
> > >> uptill
> > >>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
> > >>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> > >>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
> > >>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time a
> new
> > >> commit
> > >>>>>>>>>>>>> is
> > >>>>>>>>>>>>>> done this will also get merged.
> > >>>>>>>>>>>>>> 5.  There should always be a continuous flow from master
> to
> > >>>>>> feature
> > >>>>>>>>>>>>>> branches. Meaning all feature branch owners should
> > proactively
> > >>>>>> take
> > >>>>>>>>>>>>>> any new commits from master by doing a merge from master
> > >>>>>>>>>>>>>> 6.  The commits from feature branch will make to master on
> > >> code
> > >>>>>>>>>>>>>> complete through a merge.
> > >>>>>>>>>>>>>> 7.  There should never be a merge from master to release
> > >> branches
> > >>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor
> > release)
> > >>>>>>>>>>>>>> should have atleast bug id and correct author information
> > >>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
> > >>>>>>>>>> <committer>
> > >>>>>>>>>>>>>> for CASSANDRA-<ticket>
> > >>>>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
> > >> any bug
> > >>>>>>>>>>>>>> in jira can be marked with fix version current
> release(4.4)
> > >> only
> > >>>>>> on
> > >>>>>>>>>>>>>> RM's approval and only they can go to the release branch.
> > >> This
> > >>>>>> can be
> > >>>>>>>>>>>>>> done through jira and with certain rules.(may be using
> jira
> > >> vote?)
> > >>>>>>>>>>>>>> this would save the cherry-picking time and another branch
> > >>>>>>>>>> maintenance.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Ref:
> > >>>>>>>>>>>>>>
> > >>>>>>
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> > >>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> ~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>*™*
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --
> > >>>>>>>>>>>> *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
> > >>
> > >>
> > >
> > >
> > > --
> > >
> > >
> > > *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.
> >
> >
>



-- 
*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: [DISCUSS][PROPOSAL] git workflow

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

Must it start today, or when (if) the vote passes? Feature freeze for 4.5
has theoretically passed, so basically master branch should now be work in
progress towards a stable branch.

So I'd say; create a 'develop' branch off the current master.

Keep master as is, and only merge bugfixes until it is deemed stable and
4.5 is released.

4.6 development and new features goes into branches of 'develop'.

Erik
23. juli 2014 18:30 skrev "Sebastien Goasguen" <ru...@gmail.com> følgende:

>
> On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com> wrote:
>
> > Let me ask the question, why have master be develop and a release branch
> be
> > "master"? If we are going to follow gitflow, why not just stick with the
> > norm? If master is the development branch, it might not be stable. I
> think
> > the goal here is that we have an obvious stable branch. Anyone could come
> > check out master and have the latest useable.
>
> I am in favor of following the norm, so ideally master should be our
> stable branch (agreed).
>
> The issue is with the transition.
>
> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally we
> could start a stable branch of this tag and build up bug fix releases all
> the way to 4.5 from there.
>
> But all features for 4.5 are already in master.
>
> So if we create a 'develop' branch of master and stabilize 'master' then
> develop is now started from a stable tag (4.4.0).
>
> So what's the best way to flip ? There is most likely some git magic that
> can we do.
>
>
> The new git workflow and the transition process need to be part of a
> proposal that we get consensus on.
>
> getting there :)
>
> -seb
>
> >
> > Also, I'm struggling to understand the benefit of cherry-pick. If you
> > completely squash history, you lose a tremendous amount of context,
> which I
> > use extensively to figure out why a bug is the way it is. Only knowing
> that
> > the branch was merged at a given point in time doesn't give any context.
> > Seeing the individual commit history of the branch helps to preserve the
> > rationale for why the code was written the way it was. In theory if every
> > change starts out as a branch (feature, hotfix, release), then why not
> just
> > merge the branch once it is in a good and acceptable state?
> >
> > I also agree with Mike that this will have to be a transition over time.
> It
> > will take some time to clean up master to the point where it can be
> > considered a solid stable branch. Possibly as part of the 4.5 release.
> >
> >
> > On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <ru...@gmail.com>
> > wrote:
> >
> >>
> >> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
> >> wrote:
> >>
> >>> Sebastien,
> >>>
> >>> It seems we can do what you are calling for is creating a branch
> >>> called 'release'. We can merge back into that branch from 4.4, master,
> >>> 4.3. I would like to see people that want a feature or bug fix in a
> >>> branch make a fork of that branch and when that fork is working do a
> >>> cherry-pick. The -forward concept is now used for that but it is
> >>> broken because more then for one piece of work there are commits on
> >>> it. This caused me conflicts during the release. Especially painfull
> >>> as not all was intended to get into the release. We can create this
> >>> 'release' branch now on the basis of 4.4 and start pulling in changes.
> >>
> >> Yes, that's what I am thinking about too, so +1
> >>
> >> Our master would become the -develop- in gitflow terms
> >> The release branch you mention would become the -master- in gitflow
> terms
> >>
> >> If we start now, indeed we can create 'release' from 4.4 release tag
> >> (voted and shipped).
> >>
> >> That means that to create 4.5 we will need to merge features back into
> >> 'release'. it might be messy because some of those features are already
> in
> >> our current master.
> >>
> >> But all of this will keep 'release' clean (we can keep track of bugs and
> >> features that are in it in CHANGES file etc..)
> >>
> >>
> >>> There is a question of control. Do we allow all committers to manage
> >>> the release? I am for that but can imagine not everybody is.
> >>>
> >>
> >> At first I would say that only the RM can commit to 'release'. As we get
> >> the CI in place  we could relax this and allow commits that pass the CI
> to
> >> get into 'release', but right now I would vote for a tighter control of
> >> 'release'.
> >>
> >>> rule number 1 will be: you are going to do something to the code, you
> >>> start by creating a branch.
> >>>
> >>> right?
> >>>
> >>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <ru...@gmail.com>
> >> wrote:
> >>>>
> >>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
> >> wrote:
> >>>>
> >>>>> Hey everyone,
> >>>>>
> >>>>> I've been a developer for a handful of years and have had my share of
> >>>>> experience with different version control systems.  I've used (for
> >> better
> >>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>>>
> >>>>> Each of these solutions offers their own unique set of features,
> >> strengths
> >>>>> and weaknesses.  As there are so many systems that are good at
> specific
> >>>>> things, it seems best to use the features that the chosen system is
> >> best at.
> >>>>>
> >>>>> Git is great at branching, merging and using that structure to
> >> maintain and
> >>>>> control how changes get into the primary branches.  Git tools even
> make
> >>>>> this easy by integrating directly into the "Gitflow" to make
> branching
> >> and
> >>>>> merging that much easier.  It would seem counter-intuitive to NOT
> make
> >> use
> >>>>> of these built-in capabilities.
> >>>>>
> >>>>> In addition to that, I know that the current method of change
> >> management is
> >>>>> incredibly frustrating to work with, and works directly against the
> >> way a
> >>>>> typical Git user would expect it to be structured.  I should NEVER
> have
> >>>>> problem compiling and running something on master.  I should not have
> >>>>> problems building anything on a release branch.  A feature/bugfix
> >> branch is
> >>>>> where things can be, and often are, broken or unstable.  There have
> >> been
> >>>>> many times working in Cloudstack where I've had to search for a
> stable
> >>>>> revision on master, and that's just plain wrong.
> >>>>>
> >>>>> I do realize that having this many developers working on so many
> >> features
> >>>>> and bugfixes will result in a large number of branches.  I don't
> >> believe
> >>>>> this is a good argument against using a branching method, though - I
> >>>>> believe that the current system is even more confusing and difficult
> >> to use.
> >>>>>
> >>>>> I could pontificate on change management quite a bit more, but my
> >> opinion
> >>>>> in summary would basically be:  use Git the way it was meant to be
> >> used,
> >>>>> and things will be better.  Just my two cents.
> >>>>>
> >>>>> Sam
> >>>>>
> >>>>>
> >>>>
> >>>> Sam, I think we are in agreement (at least with folks who responded to
> >> this thread).
> >>>> Or maybe I am not reading your mail right and you don't agree with
> Leo ?
> >>>>
> >>>> My own take and reason for calling for a change we are currently doing
> >> things is mostly due to the way we release.
> >>>>
> >>>> I would like to see a stable master (and I think we are in agreement
> >> with that).
> >>>> That means that development should not happen on master and that every
> >> commit that lands on master should be shippable.
> >>>>
> >>>> I personally have no issues with cherry-picking. So I would be fine
> >> cherry picking from a hot-fix branch into master, to fix a bug.
> >>>> The end result is that the next commit on master would still mean
> >> master is shippable/releasable.
> >>>>
> >>>> If we agree with this basic concept. The question becomes how do we
> get
> >> there, considering that master is now full of dev work and potential
> bug.
> >>>> The only releasable product we have are on the 4.3, 4.4 and previous
> >> release branches.
> >>>>
> >>>> Ideally, I would like to see master becomes 4.4. And work our way
> back,
> >> merging the new features that are already in master into the new master
> >> (based on 4.4).
> >>>> This could be quite complicated but we need to do it (or something
> like
> >> it).
> >>>>
> >>>> To move forward, we should make a proposal to the list and call for a
> >> vote.
> >>>>
> >>>> Any takers to start a wiki page proposing a new git process and how we
> >> could move to it (transition path) ?
> >>>>
> >>>>
> >>>> -Sebastien
> >>>>
> >>>>
> >>>>>
> >>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
> >> LSimons@schubergphilis.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Hey folks,
> >>>>>>
> >>>>>> With 4.4.0 tagged, is now an opportune time to go and implement
> this?
> >>>>>>
> >>>>>> I would enthousiastically +1 and get crackin', but I’m not a
> >> committer so
> >>>>>> its not that practical for me to volunteer!
> >>>>>>
> >>>>>> I wanted to point out atlassian’s description of gitflow
> >>>>>>
> >>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
> >>>>>>
> >>>>>> which might be easier to read.
> >>>>>>
> >>>>>> Similarly, the git-flow scripts that help out with implementing this
> >> stuff
> >>>>>>
> >>>>>> https://github.com/nvie/gitflow
> >>>>>>
> >>>>>> they also describe the relationship between gitflow and dealing with
> >>>>>> multiple remotes
> >>>>>>
> >>>>>> https://www.atlassian.com/git/workflows#!pull-request
> >>>>>>
> >>>>>> Finally note atlassian’s free sourcetree GUI has built-in support
> for
> >>>>>> git-flow
> >>>>>>
> >>>>>> http://www.sourcetreeapp.com/
> >>>>>>
> >>>>>> Because cloudstack currently is full of rebasing and squashing and
> >>>>>> cherry-picking, you get very little benefit from a tree
> visualization
> >> tool
> >>>>>> (like this or gitk or ...) right now, but it would be *great* to
> have
> >> going
> >>>>>> forward.
> >>>>>>
> >>>>>>
> >>>>>> cheers,
> >>>>>>
> >>>>>>
> >>>>>> Leo
> >>>>>>
> >>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <ru...@gmail.com>
> >> wrote:
> >>>>>>
> >>>>>>> I would like to re-start this discussion.
> >>>>>>>
> >>>>>>> Rajani made some good points and someone mentioned Gitflow:
> >>>>>>>
> >>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>
> >>>>>>> Thinking about our release procedure, we clearly need more tests
> and
> >> a
> >>>>>> CI. However it looks like this is going to take some time.
> >>>>>>>
> >>>>>>> In the meantime I think there is nothing preventing us from
> agreeing
> >> to
> >>>>>> 'git practices', we don't need tests or new infra, we just need to
> >> agree on
> >>>>>> the git workflow.
> >>>>>>>
> >>>>>>> Right now Master is really a development branch, we should make it
> a
> >>>>>> stable branch for production with very few commits.
> >>>>>>> This does not mean that we would release less, in contrary this
> would
> >>>>>> ensure that a commit to master means it's a production release.
> >>>>>>>
> >>>>>>> In addition gitflow [1] does not do cherry-picks (gets back to
> >> Rajani's
> >>>>>> point) everything is based on merges.
> >>>>>>>
> >>>>>>> I am of the opinion that git flow provides a nice process. It
> >> basically
> >>>>>> freezes master. Development happens in a 'develop' branch, releases
> >>>>>> branches are branched off of that and merged into master and back
> into
> >>>>>> develop….etc
> >>>>>>>
> >>>>>>> Please read [1] it's a good read.
> >>>>>>>
> >>>>>>> And let's discuss,
> >>>>>>>
> >>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>
> >>>>>>> -Sebastien
> >>>>>>>
> >>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
> >> Rajani.Karuturi@citrix.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> There is also the problem of cherry-picking.
> >>>>>>>> As a contributor, I always endup creating multiple patches for
> each
> >>>>>> branch as they don’t cleanly apply on the upward branches. which
> means
> >>>>>> distinct commits for each branch and I don’t easily know which all
> >> branches
> >>>>>> my commit exists unless I do grep.
> >>>>>>>> if we follow merging strategy properly, apart from the first merge
> >> of
> >>>>>> the branch, everything else on top of it should be a painless merge.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ~Rajani
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> I think many of the bullet points are what we are currently doing
> >>>>>>>>> (guidelines for commit comments, feature branches need to stay in
> >> sync
> >>>>>> with
> >>>>>>>>> master, no back-merging). I also think that much of what we do
> now
> >> is
> >>>>>> done
> >>>>>>>>> the way it is simply because there *are* vast changes between
> >> versions.
> >>>>>>>>> Classes are getting shuffled around and changed all the time. If
> >> its
> >>>>>>>>> feasible to merge branch fixes to master, that's fine, but some
> >> quick
> >>>>>> tests
> >>>>>>>>> seem to indicate that this will be messy getting started.
> >>>>>>>>>
> >>>>>>>>> That leaves us with how we do releases. I'm fine with having
> single
> >>>>>>>>> branches for major releases(4.3) and tagging the commits where
> each
> >>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember why
> we
> >> went
> >>>>>>>>> with the -forward, I'm sure it's in the mailing list somewhere,
> but
> >>>>>> one of
> >>>>>>>>> the nice things it provides is the ability for the release
> manager
> >> to
> >>>>>>>>> control what changes are made during code freeze while giving
> >> people a
> >>>>>>>>> place to stage fixes (though admittedly this is not always
> >> followed).
> >>>>>>>>> Without -forward, would the flow be for each dev to have their
> own
> >>>>>> repo and
> >>>>>>>>> issue pull requests for bugfixes?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> >>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Any other suggestions/objections/comments??
> >>>>>>>>>> Can we discuss this in detail and agree to a process??
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ~Rajani
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> >>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
> >>>>>> merge(merge -s
> >>>>>>>>>> ours) for it and git will assume its merged but will not bring
> in
> >> any
> >>>>>>>>>> changes.
> >>>>>>>>>>>
> >>>>>>>>>>> If the branches diverged a lot, for example after a major
> >> rewrite, we
> >>>>>>>>>> could stop merging to that branch and above and make the fix
> >> manually.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> ~Rajani
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Yep, that's what I was referring to in that a particular fix
> >> for an
> >>>>>> old
> >>>>>>>>>>>> release may not apply to newer versions. That does happen.
> >>>>>>>>>>>>
> >>>>>>>>>>>> We used to mark those as "don't need to merge to branch x" in
> >> SVN
> >>>>>> and
> >>>>>>>>>> then
> >>>>>>>>>>>> you handed it however made sense on the applicable branch(es).
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>>>>>>>>> Stephen.Turner@citrix.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
> >> has to
> >>>>>> be
> >>>>>>>>>>>>> rewritten for newer versions because the code has changed?
> >> Don't
> >>>>>> the
> >>>>>>>>>>>>> branches diverge and you end up cherry-picking after that?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Stephen Turner
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> >>>>>>>>>>>>> Sent: 30 May 2014 18:48
> >>>>>>>>>>>>> To: dev@cloudstack.apache.org
> >>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think this flow is something we should seriously consider.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I find cherry picking from branch to branch to be error prone
> >> in
> >>>>>> that
> >>>>>>>>>> it's
> >>>>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
> >>>>>> branches
> >>>>>>>>>> and
> >>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
> >> related.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> When I worked at HP, we had automated tools check to see if
> you
> >>>>>>>>>> checked a
> >>>>>>>>>>>>> fix into a prior release, but not later releases. In such a
> >>>>>> situation,
> >>>>>>>>>> you
> >>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
> >> was no
> >>>>>>>>>> longer
> >>>>>>>>>>>>> applicable in the later release(s), so you needed to mark it
> as
> >>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure about
> Git).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Our current git workflow is confusing with the *forward
> >> branches
> >>>>>> and
> >>>>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
> >> commit
> >>>>>> has
> >>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
> >>>>>> contributor, I
> >>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t cleanly
> >>>>>> apply on
> >>>>>>>>>>>>>> different branches.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
> >> propose.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 1.  There should be branch for every major release(ex:
> 4.3.x,
> >>>>>> 4.4.x,
> >>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
> >> accordingly
> >>>>>> on
> >>>>>>>>>>>>>> the respective branches.
> >>>>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
> >> branches
> >>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
> >> cherry-pick,
> >>>>>>>>>>>>>> we have two physically distinct commits for the same change
> or
> >>>>>> fix and
> >>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>>>>>>>>> 4.  There should always be a continous flow from release
> >> branches
> >>>>>> to
> >>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
> >>>>>> merged(either
> >>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
> trackable
> >>>>>> with
> >>>>>>>>>>>>>> git branch --contains
> >>>>>>>>>>>>>> *   Every bug fix should always flow from minimal release
> >> uptill
> >>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
> >>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> >>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time a new
> >> commit
> >>>>>>>>>>>>> is
> >>>>>>>>>>>>>> done this will also get merged.
> >>>>>>>>>>>>>> 5.  There should always be a continuous flow from master to
> >>>>>> feature
> >>>>>>>>>>>>>> branches. Meaning all feature branch owners should
> proactively
> >>>>>> take
> >>>>>>>>>>>>>> any new commits from master by doing a merge from master
> >>>>>>>>>>>>>> 6.  The commits from feature branch will make to master on
> >> code
> >>>>>>>>>>>>>> complete through a merge.
> >>>>>>>>>>>>>> 7.  There should never be a merge from master to release
> >> branches
> >>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor
> release)
> >>>>>>>>>>>>>> should have atleast bug id and correct author information
> >>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
> >>>>>>>>>> <committer>
> >>>>>>>>>>>>>> for CASSANDRA-<ticket>
> >>>>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
> >> any bug
> >>>>>>>>>>>>>> in jira can be marked with fix version current release(4.4)
> >> only
> >>>>>> on
> >>>>>>>>>>>>>> RM's approval and only they can go to the release branch.
> >> This
> >>>>>> can be
> >>>>>>>>>>>>>> done through jira and with certain rules.(may be using jira
> >> vote?)
> >>>>>>>>>>>>>> this would save the cherry-picking time and another branch
> >>>>>>>>>> maintenance.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Ref:
> >>>>>>>>>>>>>>
> >>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ~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>*™*
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> *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
> >>
> >>
> >
> >
> > --
> >
> >
> > *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: [DISCUSS][PROPOSAL] git workflow

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

I just got caught up on this. My apologies for the delay.

I think that we are very much on the right track and that we are right to
deviate from the normal gitflow concept around the maintenance versions.
Since we will in theory have a 4.5.1 after 4.6.0 is released, there will be
some level of concurrent release management occurring. I also agree that
4.4.x is probably an overly difficult area to start this new process. The
git foo that Leo pulled out is impressive and certainly shows the sheer
pain that would be incurred by taking that path. I'm sure the transition
won't be trivial, but we don't need to make it any harder than we have to.

Thanks

-Nate


On Tue, Jul 29, 2014 at 10:00 AM, Sam Schmit <sa...@appcore.com> wrote:

> Hey guys,
>
> I totally agree that going with a git workflow is the best way forward:
>
> *  Having developers branch off of "development" onto a bugfix/feature
> branch to add or fix something in cloudstack, and controlling the merge
> back into "development".
> *  Using a "release" branch off of "development" in order to prepare a
> release candidate branch.  "Hotfix" branches can be made off of a release
> branch to fix any final issues.
> *  Standard gitflow would then have the "release" branch merge into master,
> which would contain only release-ready versions of the code.
>
> I've followed this project workflow for several projects, and it seems to
> work well.  Once we get everyone accustomed to this, I think it will
> improve everyone's ability to follow along with what is happening in the
> project, and will help project coordinators keep control of the overall
> direction.
>
> Sam
>
>
>
>
>
> On Mon, Jul 28, 2014 at 11:03 AM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
>
> > Hi,
> >
> > It took me sometime to go through all the 58 emails on this thread.
> > I suggest we need to adapt "gitflow" to our git workflow. I liked the
> > summary Rajani suggested here: http://markmail.org/message/
> > 2642ilfajkpshnfn
> >
> > Let's continue the discussion in the new thread now:
> > http://markmail.org/message/zf5yt47jqq3auswo
> >
> > Regards.
> >
> >
> > Rajani Karuturi wrote:
> >
> >> branches will be deleted after the release or hotfix if you use the
> >> git-flow commands.
> >>
> >> This would be the flow for a hotfix:
> >> 1. branch off from the release tag on master. in this case it would be
> >> release/4.4.0
> >> 2. commit the fixes in hotfix/4.4.1
> >> 3. do the release
> >> 4. merge to develop
> >> 5. merge to master and update tags
> >> 6. delete hotfix branch
> >>
> >> But, I agree that there can be a problem when we wish to do 4.4.2 if we
> >> delete the hotfix branch
> >>
> >> may be we should use git-flow support instead of hotfix which doesn’t
> >> delete the branch
> >> http://stackoverflow.com/a/16866118/201514
> >>
> >> ~Rajani
> >>
> >>
> >>
> >> On 25-Jul-2014, at 12:31 pm, Daan Hoogland<da...@gmail.com>
> >>  wrote:
> >>
> >>  Rightful question Erik,
> >>>
> >>> Rajani mentioned that release branches will be deleted. This will only
> >>> happen once the release is no longer supported. Any hotfix branch will
> >>> still have to merged on that (and master possibly) until we stop
> >>> supporting that branch.
> >>>
> >>> On the other hand you can branch from any commit.
> >>>
> >>> btw 4.4.1 is a bad example of you as we will still maintain that
> >>> without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.
> >>>
> >>> On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber<te...@gmail.com>
>  wrote:
> >>>
> >>>> This is out of my git league, but how do you handle minor versions
> that
> >>>> way?
> >>>>
> >>>> Assuming 4.8.0 is the latest stable release and HEAD on master.
> >>>>
> >>>> Then you want to release 4.4.1.
> >>>>
> >>>> First of all can you develop bugfixes for 4.4 along the way, when both
> >>>> develop and master HEAD might be hugely different?
> >>>>
> >>>> Second, can you commit  behind HEAD? You don't want the 4.4.1 release
> >>>> instead of 4.8.0 to be HEAD
> >>>>
> >>>> Someone might have good solutions to this, but if not I would propose
> to
> >>>> keep the release branches for future bugfixes.
> >>>>
> >>>> Erik
> >>>> 25. juli 2014 06:02 skrev "Rajani Karuturi"<
> Rajani.Karuturi@citrix.com>
> >>>> følgende:
> >>>>
> >>>>  On 24-Jul-2014, at 10:25 pm, Mike Tutkowski<mike.tutkowski@
> >>>>> solidfire.com>
> >>>>> wrote:
> >>>>>
> >>>>>  I believe I agree with these steps.
> >>>>>>
> >>>>>> A couple questions:
> >>>>>>
> >>>>>> Is 'master' simply always going to be equal to what's the most
> recent
> >>>>>> version of the code that's in production?
> >>>>>>
> >>>>> I think so. master will always be at the latest release and all the
> >>>>> previous releases properly tagged. The release branches would be
> >>>>> deleted
> >>>>> once release is done.
> >>>>>
> >>>>>  Also, would 'develop' be for 4.6 code then and 4.5 code would go
> >>>>>> directly
> >>>>>> into RELEASE-4.5?
> >>>>>>
> >>>>>>  Yes. 4.6 work should be done on develop branch and any 4.5 bug
> fixes
> >>>>> should be done on the 4.5 branch.
> >>>>>
> >>>>>
> >>>>>
> >>>>> ~Rajani
> >>>>>
> >>>>>
> >>>>>  On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi<
> >>>>>> Rajani.Karuturi@citrix.com>  wrote:
> >>>>>>
> >>>>>>  Hi Daan,
> >>>>>>> here is what i propose:
> >>>>>>>
> >>>>>>> 1. rename 'master' to 'develop’
> >>>>>>> 2. branch a new 'master' from '4.4’
> >>>>>>> 3. branch 'RELEASE-4.5' from the develop
> >>>>>>> 4. merge 'RELEASE-4.5' to master once the release voting is done.
> >>>>>>>
> >>>>>>> RELEASE-4.6 branch should be off develop as all the feature
> branches
> >>>>>>>
> >>>>>> would
> >>>>>
> >>>>>> be merged there before freeze for 4.6 and would be merged to master
> >>>>>>> when
> >>>>>>> the release is voted.
> >>>>>>>
> >>>>>>> The other question I have is in the step:4. how are we going to
> >>>>>>> manage
> >>>>>>> fixes to 4.5 post branch cut?  ( assuming no features as the freeze
> >>>>>>> is
> >>>>>>>
> >>>>>> done)
> >>>>>
> >>>>>> ~Rajani
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 24-Jul-2014, at 11:52 am, Daan Hoogland<daan.hoogland@gmail.com
> >
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>  Mike, Rajani,
> >>>>>>>>
> >>>>>>>> Sebastien's point was that the current 4.4 is the closest we have
> >>>>>>>> to a
> >>>>>>>> releasable branch. I don't mind enting on master but it will
> require
> >>>>>>>> more fixing. In general all of this will require some RM work of
> all
> >>>>>>>> committers. Please ammend my little proposal if you will.
> >>>>>>>>
> >>>>>>>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
> >>>>>>>> <Ra...@citrix.com>  wrote:
> >>>>>>>>
> >>>>>>>>> I agree with mike. I think we should start 4.5 from where master
> is
> >>>>>>>>>
> >>>>>>>> now
> >>>>>
> >>>>>> Also create a develop branch from master and continue future work
> for
> >>>>>>>>>
> >>>>>>>> 4.6 there.
> >>>>>>>
> >>>>>>>> I am not clear on how the release branches are going to be
> >>>>>>>>> maintained.
> >>>>>>>>> Are we saying we would create 4.5-RELEASE branch which is
> >>>>>>>>> essentially
> >>>>>>>>>
> >>>>>>>> same as our current -FORWARD branch and continue cherry-picking?
> >>>>>>>
> >>>>>>>> I would prefer merges to cherry-picks.
> >>>>>>>>> Also, I think we should allow committers to commit to the RELEASE
> >>>>>>>>>
> >>>>>>>> branch after discussing about it on dev@ and have RM closely
> >>>>>>> monitor
> >>>>>>>
> >>>>>> them.
> >>>>>
> >>>>>> Any commit intended for 4.5 RELEASE should be checked in after
> >>>>>>>>>
> >>>>>>>> discussion in the 4.5 Release branch and then merged to develop
> >>>>>>> branch.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> ~Rajani
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski<
> >>>>>>>>>
> >>>>>>>> mike.tutkowski@solidfire.com>  wrote:
> >>>>>>>
> >>>>>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
> >>>>>>>>>>
> >>>>>>>>> left
> >>>>>
> >>>>>> off
> >>>>>>>
> >>>>>>>> and then merge features from develop into 4.5.
> >>>>>>>>>>
> >>>>>>>>>> Why don't we instead start 4.5 where master is now with the
> >>>>>>>>>>
> >>>>>>>>> assumption
> >>>>>
> >>>>>> that
> >>>>>>>
> >>>>>>>> since we are past Feature Freeze for 4.5 that master is stable
> >>>>>>>>>>
> >>>>>>>>> enough?
> >>>>>
> >>>>>>
> >>>>>>>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland<
> >>>>>>>>>>
> >>>>>>>>> daan.hoogland@gmail.com>
> >>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>  so to start formulate a proposal:
> >>>>>>>>>>>
> >>>>>>>>>>> all work shall be done in a new branch (it is advisable to
> prefix
> >>>>>>>>>>>
> >>>>>>>>>> your
> >>>>>
> >>>>>> branches with your id)
> >>>>>>>>>>> when working, features will be cherry-picked/merged into the
> >>>>>>>>>>> release
> >>>>>>>>>>> branch they are for and next into master.
> >>>>>>>>>>> hotfixes will be done in<branchname>-hotfixes
> >>>>>>>>>>>
> >>>>>>>>>>> as transition we will
> >>>>>>>>>>>
> >>>>>>>>>>> rename 'master' to 'develop'
> >>>>>>>>>>> branch a new 'master' from '4.4'
> >>>>>>>>>>> branch '4.5' from the new 'master'
> >>>>>>>>>>> merge any features from the new 'develop' to '4.5' and 'master'
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen<
> >>>>>>>>>>>
> >>>>>>>>>> runseb@gmail.com
> >>>>>
> >>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen<
> >>>>>>>>>>>> runseb@gmail.com
> >>>>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon<
> >>>>>>>>>>>>>
> >>>>>>>>>>>> nate.gordon@appcore.com>
> >>>>>
> >>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Let me ask the question, why have master be develop and a
> >>>>>>>>>>>>>> release
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> branch be
> >>>>>>>>>>>
> >>>>>>>>>>>> "master"? If we are going to follow gitflow, why not just
> stick
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> with
> >>>>>>>
> >>>>>>>> the
> >>>>>>>>>>>
> >>>>>>>>>>>> norm? If master is the development branch, it might not be
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> stable.
> >>>>>
> >>>>>> I
> >>>>>>>
> >>>>>>>> think
> >>>>>>>>>>>
> >>>>>>>>>>>> the goal here is that we have an obvious stable branch. Anyone
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> could
> >>>>>>>
> >>>>>>>> come
> >>>>>>>>>>>
> >>>>>>>>>>>> check out master and have the latest useable.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> I am in favor of following the norm, so ideally master should
> >>>>>>>>>>>>> be
> >>>>>>>>>>>>>
> >>>>>>>>>>>> our
> >>>>>
> >>>>>> stable branch (agreed).
> >>>>>>>>>>>
> >>>>>>>>>>>> The issue is with the transition.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag),
> so
> >>>>>>>>>>>>>
> >>>>>>>>>>>> ideally
> >>>>>>>
> >>>>>>>> we could start a stable branch of this tag and build up bug fix
> >>>>>>>>>>>
> >>>>>>>>>> releases
> >>>>>>>
> >>>>>>>> all the way to 4.5 from there.
> >>>>>>>>>>>
> >>>>>>>>>>>> But all features for 4.5 are already in master.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So if we create a 'develop' branch of master and stabilize
> >>>>>>>>>>>>>
> >>>>>>>>>>>> 'master'
> >>>>>
> >>>>>> then develop is now started from a stable tag (4.4.0).
> >>>>>>>>>>>
> >>>>>>>>>>>> *not* started from a stable tag, and merges will be tricky,
> no ?
> >>>>>>>>>>>>
> >>>>>>>>>>>>  So what's the best way to flip ? There is most likely some
> git
> >>>>>>>>>>>>>
> >>>>>>>>>>>> magic
> >>>>>
> >>>>>> that can we do.
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> The new git workflow and the transition process need to be
> part
> >>>>>>>>>>>>>
> >>>>>>>>>>>> of a
> >>>>>
> >>>>>> proposal that we get consensus on.
> >>>>>>>>>>>
> >>>>>>>>>>>> getting there :)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -seb
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>  Also, I'm struggling to understand the benefit of
> >>>>>>>>>>>>>> cherry-pick. If
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> you
> >>>>>>>
> >>>>>>>> completely squash history, you lose a tremendous amount of
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> context,
> >>>>>
> >>>>>> which I
> >>>>>>>>>>>
> >>>>>>>>>>>> use extensively to figure out why a bug is the way it is. Only
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> knowing
> >>>>>>>
> >>>>>>>> that
> >>>>>>>>>>>
> >>>>>>>>>>>> the branch was merged at a given point in time doesn't give
> any
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> context.
> >>>>>>>>>>>
> >>>>>>>>>>>> Seeing the individual commit history of the branch helps to
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> preserve
> >>>>>>>
> >>>>>>>> the
> >>>>>>>>>>>
> >>>>>>>>>>>> rationale for why the code was written the way it was. In
> theory
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> if
> >>>>>
> >>>>>> every
> >>>>>>>>>>>
> >>>>>>>>>>>> change starts out as a branch (feature, hotfix, release), then
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> why
> >>>>>
> >>>>>> not
> >>>>>>>
> >>>>>>>> just
> >>>>>>>>>>>
> >>>>>>>>>>>> merge the branch once it is in a good and acceptable state?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I also agree with Mike that this will have to be a
> transition
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> over
> >>>>>
> >>>>>> time. It
> >>>>>>>>>>>
> >>>>>>>>>>>> will take some time to clean up master to the point where it
> can
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> be
> >>>>>
> >>>>>> considered a solid stable branch. Possibly as part of the 4.5
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> release.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen<
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> runseb@gmail.com
> >>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>  On Jul 23, 2014, at 11:38 AM, daan Hoogland<
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> daan.hoogland@gmail.com>
> >>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>  Sebastien,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It seems we can do what you are calling for is creating a
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> branch
> >>>>>
> >>>>>> called 'release'. We can merge back into that branch from 4.4,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> master,
> >>>>>>>>>>>
> >>>>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> in a
> >>>>>>>
> >>>>>>>> branch make a fork of that branch and when that fork is working
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> do a
> >>>>>>>
> >>>>>>>> cherry-pick. The -forward concept is now used for that but it
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> is
> >>>>>
> >>>>>> broken because more then for one piece of work there are
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> commits
> >>>>>
> >>>>>> on
> >>>>>>>
> >>>>>>>> it. This caused me conflicts during the release. Especially
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> painfull
> >>>>>>>
> >>>>>>>> as not all was intended to get into the release. We can create
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> this
> >>>>>>>
> >>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> changes.
> >>>>>>>>>>>
> >>>>>>>>>>>> Yes, that's what I am thinking about too, so +1
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Our master would become the -develop- in gitflow terms
> >>>>>>>>>>>>>>> The release branch you mention would become the -master- in
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> gitflow
> >>>>>>>
> >>>>>>>> terms
> >>>>>>>>>>>
> >>>>>>>>>>>> If we start now, indeed we can create 'release' from 4.4
> release
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> tag
> >>>>>>>
> >>>>>>>> (voted and shipped).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> That means that to create 4.5 we will need to merge
> features
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> back
> >>>>>
> >>>>>> into
> >>>>>>>
> >>>>>>>> 'release'. it might be messy because some of those features are
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> already in
> >>>>>>>>>>>
> >>>>>>>>>>>> our current master.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But all of this will keep 'release' clean (we can keep
> track
> >>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> bugs
> >>>>>>>
> >>>>>>>> and
> >>>>>>>>>>>
> >>>>>>>>>>>> features that are in it in CHANGES file etc..)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>  There is a question of control. Do we allow all committers
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> manage
> >>>>>>>
> >>>>>>>> the release? I am for that but can imagine not everybody is.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>  At first I would say that only the RM can commit to
> >>>>>>>>>>>>>>> 'release'.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> As
> >>>>>
> >>>>>> we
> >>>>>>>
> >>>>>>>> get
> >>>>>>>>>>>
> >>>>>>>>>>>> the CI in place  we could relax this and allow commits that
> pass
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> the
> >>>>>>>
> >>>>>>>> CI to
> >>>>>>>>>>>
> >>>>>>>>>>>> get into 'release', but right now I would vote for a tighter
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> control
> >>>>>>>
> >>>>>>>> of
> >>>>>>>>>>>
> >>>>>>>>>>>> 'release'.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>  rule number 1 will be: you are going to do something to
> the
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> code, you
> >>>>>>>
> >>>>>>>> start by creating a branch.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> right?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen<
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> runseb@gmail.com>
> >>>>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit<
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> sam.schmit@appcore.com>
> >>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hey everyone,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I've been a developer for a handful of years and have
> had
> >>>>>>>>>>>>>>>>>> my
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> share
> >>>>>>>
> >>>>>>>> of
> >>>>>>>>>>>
> >>>>>>>>>>>> experience with different version control systems.  I've used
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> (for
> >>>>>>>
> >>>>>>>> better
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Each of these solutions offers their own unique set of
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> features,
> >>>>>>>
> >>>>>>>> strengths
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> and weaknesses.  As there are so many systems that are
> good
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> at
> >>>>>
> >>>>>> specific
> >>>>>>>>>>>
> >>>>>>>>>>>> things, it seems best to use the features that the chosen
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> system is
> >>>>>>>
> >>>>>>>> best at.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Git is great at branching, merging and using that
> structure
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> to
> >>>>>
> >>>>>> maintain and
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> control how changes get into the primary branches.  Git
> >>>>>>>>>>>>>>>>>> tools
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> even
> >>>>>>>
> >>>>>>>> make
> >>>>>>>>>>>
> >>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> branching
> >>>>>>>>>>>
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> merging that much easier.  It would seem counter-intuitive
> >>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> NOT
> >>>>>>>
> >>>>>>>> make
> >>>>>>>>>>>
> >>>>>>>>>>>> use
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> of these built-in capabilities.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> In addition to that, I know that the current method of
> >>>>>>>>>>>>>>>>>> change
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> management is
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> incredibly frustrating to work with, and works directly
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> against the
> >>>>>>>
> >>>>>>>> way a
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> typical Git user would expect it to be structured.  I
> should
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> NEVER
> >>>>>>>
> >>>>>>>> have
> >>>>>>>>>>>
> >>>>>>>>>>>> problem compiling and running something on master.  I should
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> not
> >>>>>>>
> >>>>>>>> have
> >>>>>>>>>>>
> >>>>>>>>>>>> problems building anything on a release branch.  A
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> feature/bugfix
> >>>>>>>
> >>>>>>>> branch is
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> where things can be, and often are, broken or unstable.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> There
> >>>>>
> >>>>>> have
> >>>>>>>
> >>>>>>>> been
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> many times working in Cloudstack where I've had to search
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> for a
> >>>>>
> >>>>>> stable
> >>>>>>>>>>>
> >>>>>>>>>>>> revision on master, and that's just plain wrong.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I do realize that having this many developers working on
> >>>>>>>>>>>>>>>>>> so
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> many
> >>>>>>>
> >>>>>>>> features
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> and bugfixes will result in a large number of branches.  I
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> don't
> >>>>>>>
> >>>>>>>> believe
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> this is a good argument against using a branching method,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> though -
> >>>>>>>
> >>>>>>>> I
> >>>>>>>>>>>
> >>>>>>>>>>>> believe that the current system is even more confusing and
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> difficult
> >>>>>>>>>>>
> >>>>>>>>>>>> to use.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I could pontificate on change management quite a bit more,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> but
> >>>>>
> >>>>>> my
> >>>>>>>
> >>>>>>>> opinion
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> in summary would basically be:  use Git the way it was
> meant
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> to be
> >>>>>>>
> >>>>>>>> used,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> and things will be better.  Just my two cents.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Sam
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>  Sam, I think we are in agreement (at least with folks
> who
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> responded
> >>>>>>>
> >>>>>>>> to
> >>>>>>>>>>>
> >>>>>>>>>>>> this thread).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Or maybe I am not reading your mail right and you don't
> >>>>>>>>>>>>>>>>> agree
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> with
> >>>>>>>
> >>>>>>>> Leo ?
> >>>>>>>>>>>
> >>>>>>>>>>>> My own take and reason for calling for a change we are
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> currently
> >>>>>
> >>>>>> doing
> >>>>>>>>>>>
> >>>>>>>>>>>> things is mostly due to the way we release.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I would like to see a stable master (and I think we are in
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> agreement
> >>>>>>>
> >>>>>>>> with that).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That means that development should not happen on master
> and
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> that
> >>>>>
> >>>>>> every
> >>>>>>>>>>>
> >>>>>>>>>>>> commit that lands on master should be shippable.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I personally have no issues with cherry-picking. So I
> would
> >>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> fine
> >>>>>>>
> >>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The end result is that the next commit on master would
> still
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> mean
> >>>>>>>
> >>>>>>>> master is shippable/releasable.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If we agree with this basic concept. The question becomes
> >>>>>>>>>>>>>>>>> how
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> do we
> >>>>>>>
> >>>>>>>> get
> >>>>>>>>>>>
> >>>>>>>>>>>> there, considering that master is now full of dev work and
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> potential
> >>>>>>>
> >>>>>>>> bug.
> >>>>>>>>>>>
> >>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> previous
> >>>>>>>
> >>>>>>>> release branches.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work
> >>>>>>>>>>>>>>>>> our
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> way
> >>>>>>>
> >>>>>>>> back,
> >>>>>>>>>>>
> >>>>>>>>>>>> merging the new features that are already in master into the
> new
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
>



-- 


*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: [DISCUSS][PROPOSAL] git workflow

[Sam Schmit <sa...@appcore.com>]

Hey guys,

I totally agree that going with a git workflow is the best way forward:

*  Having developers branch off of "development" onto a bugfix/feature
branch to add or fix something in cloudstack, and controlling the merge
back into "development".
*  Using a "release" branch off of "development" in order to prepare a
release candidate branch.  "Hotfix" branches can be made off of a release
branch to fix any final issues.
*  Standard gitflow would then have the "release" branch merge into master,
which would contain only release-ready versions of the code.

I've followed this project workflow for several projects, and it seems to
work well.  Once we get everyone accustomed to this, I think it will
improve everyone's ability to follow along with what is happening in the
project, and will help project coordinators keep control of the overall
direction.

Sam





On Mon, Jul 28, 2014 at 11:03 AM, Rohit Yadav <ro...@shapeblue.com>
wrote:

> Hi,
>
> It took me sometime to go through all the 58 emails on this thread.
> I suggest we need to adapt "gitflow" to our git workflow. I liked the
> summary Rajani suggested here: http://markmail.org/message/
> 2642ilfajkpshnfn
>
> Let's continue the discussion in the new thread now:
> http://markmail.org/message/zf5yt47jqq3auswo
>
> Regards.
>
>
> Rajani Karuturi wrote:
>
>> branches will be deleted after the release or hotfix if you use the
>> git-flow commands.
>>
>> This would be the flow for a hotfix:
>> 1. branch off from the release tag on master. in this case it would be
>> release/4.4.0
>> 2. commit the fixes in hotfix/4.4.1
>> 3. do the release
>> 4. merge to develop
>> 5. merge to master and update tags
>> 6. delete hotfix branch
>>
>> But, I agree that there can be a problem when we wish to do 4.4.2 if we
>> delete the hotfix branch
>>
>> may be we should use git-flow support instead of hotfix which doesn’t
>> delete the branch
>> http://stackoverflow.com/a/16866118/201514
>>
>> ~Rajani
>>
>>
>>
>> On 25-Jul-2014, at 12:31 pm, Daan Hoogland<da...@gmail.com>
>>  wrote:
>>
>>  Rightful question Erik,
>>>
>>> Rajani mentioned that release branches will be deleted. This will only
>>> happen once the release is no longer supported. Any hotfix branch will
>>> still have to merged on that (and master possibly) until we stop
>>> supporting that branch.
>>>
>>> On the other hand you can branch from any commit.
>>>
>>> btw 4.4.1 is a bad example of you as we will still maintain that
>>> without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.
>>>
>>> On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber<te...@gmail.com>  wrote:
>>>
>>>> This is out of my git league, but how do you handle minor versions that
>>>> way?
>>>>
>>>> Assuming 4.8.0 is the latest stable release and HEAD on master.
>>>>
>>>> Then you want to release 4.4.1.
>>>>
>>>> First of all can you develop bugfixes for 4.4 along the way, when both
>>>> develop and master HEAD might be hugely different?
>>>>
>>>> Second, can you commit  behind HEAD? You don't want the 4.4.1 release
>>>> instead of 4.8.0 to be HEAD
>>>>
>>>> Someone might have good solutions to this, but if not I would propose to
>>>> keep the release branches for future bugfixes.
>>>>
>>>> Erik
>>>> 25. juli 2014 06:02 skrev "Rajani Karuturi"<Ra...@citrix.com>
>>>> følgende:
>>>>
>>>>  On 24-Jul-2014, at 10:25 pm, Mike Tutkowski<mike.tutkowski@
>>>>> solidfire.com>
>>>>> wrote:
>>>>>
>>>>>  I believe I agree with these steps.
>>>>>>
>>>>>> A couple questions:
>>>>>>
>>>>>> Is 'master' simply always going to be equal to what's the most recent
>>>>>> version of the code that's in production?
>>>>>>
>>>>> I think so. master will always be at the latest release and all the
>>>>> previous releases properly tagged. The release branches would be
>>>>> deleted
>>>>> once release is done.
>>>>>
>>>>>  Also, would 'develop' be for 4.6 code then and 4.5 code would go
>>>>>> directly
>>>>>> into RELEASE-4.5?
>>>>>>
>>>>>>  Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
>>>>> should be done on the 4.5 branch.
>>>>>
>>>>>
>>>>>
>>>>> ~Rajani
>>>>>
>>>>>
>>>>>  On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi<
>>>>>> Rajani.Karuturi@citrix.com>  wrote:
>>>>>>
>>>>>>  Hi Daan,
>>>>>>> here is what i propose:
>>>>>>>
>>>>>>> 1. rename 'master' to 'develop’
>>>>>>> 2. branch a new 'master' from '4.4’
>>>>>>> 3. branch 'RELEASE-4.5' from the develop
>>>>>>> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>>>>>>>
>>>>>>> RELEASE-4.6 branch should be off develop as all the feature branches
>>>>>>>
>>>>>> would
>>>>>
>>>>>> be merged there before freeze for 4.6 and would be merged to master
>>>>>>> when
>>>>>>> the release is voted.
>>>>>>>
>>>>>>> The other question I have is in the step:4. how are we going to
>>>>>>> manage
>>>>>>> fixes to 4.5 post branch cut?  ( assuming no features as the freeze
>>>>>>> is
>>>>>>>
>>>>>> done)
>>>>>
>>>>>> ~Rajani
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 24-Jul-2014, at 11:52 am, Daan Hoogland<da...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>  Mike, Rajani,
>>>>>>>>
>>>>>>>> Sebastien's point was that the current 4.4 is the closest we have
>>>>>>>> to a
>>>>>>>> releasable branch. I don't mind enting on master but it will require
>>>>>>>> more fixing. In general all of this will require some RM work of all
>>>>>>>> committers. Please ammend my little proposal if you will.
>>>>>>>>
>>>>>>>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
>>>>>>>> <Ra...@citrix.com>  wrote:
>>>>>>>>
>>>>>>>>> I agree with mike. I think we should start 4.5 from where master is
>>>>>>>>>
>>>>>>>> now
>>>>>
>>>>>> Also create a develop branch from master and continue future work for
>>>>>>>>>
>>>>>>>> 4.6 there.
>>>>>>>
>>>>>>>> I am not clear on how the release branches are going to be
>>>>>>>>> maintained.
>>>>>>>>> Are we saying we would create 4.5-RELEASE branch which is
>>>>>>>>> essentially
>>>>>>>>>
>>>>>>>> same as our current -FORWARD branch and continue cherry-picking?
>>>>>>>
>>>>>>>> I would prefer merges to cherry-picks.
>>>>>>>>> Also, I think we should allow committers to commit to the RELEASE
>>>>>>>>>
>>>>>>>> branch after discussing about it on dev@ and have RM closely
>>>>>>> monitor
>>>>>>>
>>>>>> them.
>>>>>
>>>>>> Any commit intended for 4.5 RELEASE should be checked in after
>>>>>>>>>
>>>>>>>> discussion in the 4.5 Release branch and then merged to develop
>>>>>>> branch.
>>>>>>>
>>>>>>>>
>>>>>>>>> ~Rajani
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski<
>>>>>>>>>
>>>>>>>> mike.tutkowski@solidfire.com>  wrote:
>>>>>>>
>>>>>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
>>>>>>>>>>
>>>>>>>>> left
>>>>>
>>>>>> off
>>>>>>>
>>>>>>>> and then merge features from develop into 4.5.
>>>>>>>>>>
>>>>>>>>>> Why don't we instead start 4.5 where master is now with the
>>>>>>>>>>
>>>>>>>>> assumption
>>>>>
>>>>>> that
>>>>>>>
>>>>>>>> since we are past Feature Freeze for 4.5 that master is stable
>>>>>>>>>>
>>>>>>>>> enough?
>>>>>
>>>>>>
>>>>>>>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland<
>>>>>>>>>>
>>>>>>>>> daan.hoogland@gmail.com>
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>  so to start formulate a proposal:
>>>>>>>>>>>
>>>>>>>>>>> all work shall be done in a new branch (it is advisable to prefix
>>>>>>>>>>>
>>>>>>>>>> your
>>>>>
>>>>>> branches with your id)
>>>>>>>>>>> when working, features will be cherry-picked/merged into the
>>>>>>>>>>> release
>>>>>>>>>>> branch they are for and next into master.
>>>>>>>>>>> hotfixes will be done in<branchname>-hotfixes
>>>>>>>>>>>
>>>>>>>>>>> as transition we will
>>>>>>>>>>>
>>>>>>>>>>> rename 'master' to 'develop'
>>>>>>>>>>> branch a new 'master' from '4.4'
>>>>>>>>>>> branch '4.5' from the new 'master'
>>>>>>>>>>> merge any features from the new 'develop' to '4.5' and 'master'
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen<
>>>>>>>>>>>
>>>>>>>>>> runseb@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen<
>>>>>>>>>>>> runseb@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon<
>>>>>>>>>>>>>
>>>>>>>>>>>> nate.gordon@appcore.com>
>>>>>
>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Let me ask the question, why have master be develop and a
>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>
>>>>>>>>>>>>> branch be
>>>>>>>>>>>
>>>>>>>>>>>> "master"? If we are going to follow gitflow, why not just stick
>>>>>>>>>>>>>>
>>>>>>>>>>>>> with
>>>>>>>
>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>> norm? If master is the development branch, it might not be
>>>>>>>>>>>>>>
>>>>>>>>>>>>> stable.
>>>>>
>>>>>> I
>>>>>>>
>>>>>>>> think
>>>>>>>>>>>
>>>>>>>>>>>> the goal here is that we have an obvious stable branch. Anyone
>>>>>>>>>>>>>>
>>>>>>>>>>>>> could
>>>>>>>
>>>>>>>> come
>>>>>>>>>>>
>>>>>>>>>>>> check out master and have the latest useable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> I am in favor of following the norm, so ideally master should
>>>>>>>>>>>>> be
>>>>>>>>>>>>>
>>>>>>>>>>>> our
>>>>>
>>>>>> stable branch (agreed).
>>>>>>>>>>>
>>>>>>>>>>>> The issue is with the transition.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
>>>>>>>>>>>>>
>>>>>>>>>>>> ideally
>>>>>>>
>>>>>>>> we could start a stable branch of this tag and build up bug fix
>>>>>>>>>>>
>>>>>>>>>> releases
>>>>>>>
>>>>>>>> all the way to 4.5 from there.
>>>>>>>>>>>
>>>>>>>>>>>> But all features for 4.5 are already in master.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So if we create a 'develop' branch of master and stabilize
>>>>>>>>>>>>>
>>>>>>>>>>>> 'master'
>>>>>
>>>>>> then develop is now started from a stable tag (4.4.0).
>>>>>>>>>>>
>>>>>>>>>>>> *not* started from a stable tag, and merges will be tricky, no ?
>>>>>>>>>>>>
>>>>>>>>>>>>  So what's the best way to flip ? There is most likely some git
>>>>>>>>>>>>>
>>>>>>>>>>>> magic
>>>>>
>>>>>> that can we do.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> The new git workflow and the transition process need to be part
>>>>>>>>>>>>>
>>>>>>>>>>>> of a
>>>>>
>>>>>> proposal that we get consensus on.
>>>>>>>>>>>
>>>>>>>>>>>> getting there :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> -seb
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Also, I'm struggling to understand the benefit of
>>>>>>>>>>>>>> cherry-pick. If
>>>>>>>>>>>>>>
>>>>>>>>>>>>> you
>>>>>>>
>>>>>>>> completely squash history, you lose a tremendous amount of
>>>>>>>>>>>>>>
>>>>>>>>>>>>> context,
>>>>>
>>>>>> which I
>>>>>>>>>>>
>>>>>>>>>>>> use extensively to figure out why a bug is the way it is. Only
>>>>>>>>>>>>>>
>>>>>>>>>>>>> knowing
>>>>>>>
>>>>>>>> that
>>>>>>>>>>>
>>>>>>>>>>>> the branch was merged at a given point in time doesn't give any
>>>>>>>>>>>>>>
>>>>>>>>>>>>> context.
>>>>>>>>>>>
>>>>>>>>>>>> Seeing the individual commit history of the branch helps to
>>>>>>>>>>>>>>
>>>>>>>>>>>>> preserve
>>>>>>>
>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>> rationale for why the code was written the way it was. In theory
>>>>>>>>>>>>>>
>>>>>>>>>>>>> if
>>>>>
>>>>>> every
>>>>>>>>>>>
>>>>>>>>>>>> change starts out as a branch (feature, hotfix, release), then
>>>>>>>>>>>>>>
>>>>>>>>>>>>> why
>>>>>
>>>>>> not
>>>>>>>
>>>>>>>> just
>>>>>>>>>>>
>>>>>>>>>>>> merge the branch once it is in a good and acceptable state?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I also agree with Mike that this will have to be a transition
>>>>>>>>>>>>>>
>>>>>>>>>>>>> over
>>>>>
>>>>>> time. It
>>>>>>>>>>>
>>>>>>>>>>>> will take some time to clean up master to the point where it can
>>>>>>>>>>>>>>
>>>>>>>>>>>>> be
>>>>>
>>>>>> considered a solid stable branch. Possibly as part of the 4.5
>>>>>>>>>>>>>>
>>>>>>>>>>>>> release.
>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen<
>>>>>>>>>>>>>>
>>>>>>>>>>>>> runseb@gmail.com
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  On Jul 23, 2014, at 11:38 AM, daan Hoogland<
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> daan.hoogland@gmail.com>
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  Sebastien,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It seems we can do what you are calling for is creating a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> branch
>>>>>
>>>>>> called 'release'. We can merge back into that branch from 4.4,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> master,
>>>>>>>>>>>
>>>>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> in a
>>>>>>>
>>>>>>>> branch make a fork of that branch and when that fork is working
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> do a
>>>>>>>
>>>>>>>> cherry-pick. The -forward concept is now used for that but it
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is
>>>>>
>>>>>> broken because more then for one piece of work there are
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> commits
>>>>>
>>>>>> on
>>>>>>>
>>>>>>>> it. This caused me conflicts during the release. Especially
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> painfull
>>>>>>>
>>>>>>>> as not all was intended to get into the release. We can create
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> this
>>>>>>>
>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> changes.
>>>>>>>>>>>
>>>>>>>>>>>> Yes, that's what I am thinking about too, so +1
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Our master would become the -develop- in gitflow terms
>>>>>>>>>>>>>>> The release branch you mention would become the -master- in
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> gitflow
>>>>>>>
>>>>>>>> terms
>>>>>>>>>>>
>>>>>>>>>>>> If we start now, indeed we can create 'release' from 4.4 release
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> tag
>>>>>>>
>>>>>>>> (voted and shipped).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That means that to create 4.5 we will need to merge features
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> back
>>>>>
>>>>>> into
>>>>>>>
>>>>>>>> 'release'. it might be messy because some of those features are
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> already in
>>>>>>>>>>>
>>>>>>>>>>>> our current master.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But all of this will keep 'release' clean (we can keep track
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> bugs
>>>>>>>
>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>>> features that are in it in CHANGES file etc..)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  There is a question of control. Do we allow all committers
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> manage
>>>>>>>
>>>>>>>> the release? I am for that but can imagine not everybody is.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  At first I would say that only the RM can commit to
>>>>>>>>>>>>>>> 'release'.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As
>>>>>
>>>>>> we
>>>>>>>
>>>>>>>> get
>>>>>>>>>>>
>>>>>>>>>>>> the CI in place  we could relax this and allow commits that pass
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> the
>>>>>>>
>>>>>>>> CI to
>>>>>>>>>>>
>>>>>>>>>>>> get into 'release', but right now I would vote for a tighter
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> control
>>>>>>>
>>>>>>>> of
>>>>>>>>>>>
>>>>>>>>>>>> 'release'.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  rule number 1 will be: you are going to do something to the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> code, you
>>>>>>>
>>>>>>>> start by creating a branch.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> right?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen<
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> runseb@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit<
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> sam.schmit@appcore.com>
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I've been a developer for a handful of years and have had
>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> share
>>>>>>>
>>>>>>>> of
>>>>>>>>>>>
>>>>>>>>>>>> experience with different version control systems.  I've used
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (for
>>>>>>>
>>>>>>>> better
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Each of these solutions offers their own unique set of
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> features,
>>>>>>>
>>>>>>>> strengths
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and weaknesses.  As there are so many systems that are good
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>
>>>>>> specific
>>>>>>>>>>>
>>>>>>>>>>>> things, it seems best to use the features that the chosen
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> system is
>>>>>>>
>>>>>>>> best at.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Git is great at branching, merging and using that structure
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> to
>>>>>
>>>>>> maintain and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> control how changes get into the primary branches.  Git
>>>>>>>>>>>>>>>>>> tools
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> even
>>>>>>>
>>>>>>>> make
>>>>>>>>>>>
>>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> branching
>>>>>>>>>>>
>>>>>>>>>>>> and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> merging that much easier.  It would seem counter-intuitive
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> NOT
>>>>>>>
>>>>>>>> make
>>>>>>>>>>>
>>>>>>>>>>>> use
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> of these built-in capabilities.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In addition to that, I know that the current method of
>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> management is
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> incredibly frustrating to work with, and works directly
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> against the
>>>>>>>
>>>>>>>> way a
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> typical Git user would expect it to be structured.  I should
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> NEVER
>>>>>>>
>>>>>>>> have
>>>>>>>>>>>
>>>>>>>>>>>> problem compiling and running something on master.  I should
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> not
>>>>>>>
>>>>>>>> have
>>>>>>>>>>>
>>>>>>>>>>>> problems building anything on a release branch.  A
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> feature/bugfix
>>>>>>>
>>>>>>>> branch is
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> where things can be, and often are, broken or unstable.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There
>>>>>
>>>>>> have
>>>>>>>
>>>>>>>> been
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> many times working in Cloudstack where I've had to search
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> for a
>>>>>
>>>>>> stable
>>>>>>>>>>>
>>>>>>>>>>>> revision on master, and that's just plain wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I do realize that having this many developers working on
>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> many
>>>>>>>
>>>>>>>> features
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and bugfixes will result in a large number of branches.  I
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> don't
>>>>>>>
>>>>>>>> believe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> this is a good argument against using a branching method,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> though -
>>>>>>>
>>>>>>>> I
>>>>>>>>>>>
>>>>>>>>>>>> believe that the current system is even more confusing and
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> difficult
>>>>>>>>>>>
>>>>>>>>>>>> to use.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I could pontificate on change management quite a bit more,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> but
>>>>>
>>>>>> my
>>>>>>>
>>>>>>>> opinion
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> in summary would basically be:  use Git the way it was meant
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> to be
>>>>>>>
>>>>>>>> used,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and things will be better.  Just my two cents.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Sam
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  Sam, I think we are in agreement (at least with folks who
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> responded
>>>>>>>
>>>>>>>> to
>>>>>>>>>>>
>>>>>>>>>>>> this thread).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Or maybe I am not reading your mail right and you don't
>>>>>>>>>>>>>>>>> agree
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> with
>>>>>>>
>>>>>>>> Leo ?
>>>>>>>>>>>
>>>>>>>>>>>> My own take and reason for calling for a change we are
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> currently
>>>>>
>>>>>> doing
>>>>>>>>>>>
>>>>>>>>>>>> things is mostly due to the way we release.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would like to see a stable master (and I think we are in
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> agreement
>>>>>>>
>>>>>>>> with that).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That means that development should not happen on master and
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> that
>>>>>
>>>>>> every
>>>>>>>>>>>
>>>>>>>>>>>> commit that lands on master should be shippable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I personally have no issues with cherry-picking. So I would
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> fine
>>>>>>>
>>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The end result is that the next commit on master would still
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> mean
>>>>>>>
>>>>>>>> master is shippable/releasable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If we agree with this basic concept. The question becomes
>>>>>>>>>>>>>>>>> how
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> do we
>>>>>>>
>>>>>>>> get
>>>>>>>>>>>
>>>>>>>>>>>> there, considering that master is now full of dev work and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> potential
>>>>>>>
>>>>>>>> bug.
>>>>>>>>>>>
>>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> previous
>>>>>>>
>>>>>>>> release branches.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work
>>>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> way
>>>>>>>
>>>>>>>> back,
>>>>>>>>>>>
>>>>>>>>>>>> merging the new features that are already in master into the new
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>

Re: [DISCUSS][PROPOSAL] git workflow

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

Hi,

It took me sometime to go through all the 58 emails on this thread.
I suggest we need to adapt "gitflow" to our git workflow. I liked the
summary Rajani suggested here: http://markmail.org/message/2642ilfajkpshnfn

Let's continue the discussion in the new thread now:
http://markmail.org/message/zf5yt47jqq3auswo

Regards.


Rajani Karuturi wrote:
> branches will be deleted after the release or hotfix if you use the git-flow commands.
>
> This would be the flow for a hotfix:
> 1. branch off from the release tag on master. in this case it would be release/4.4.0
> 2. commit the fixes in hotfix/4.4.1
> 3. do the release
> 4. merge to develop
> 5. merge to master and update tags
> 6. delete hotfix branch
>
> But, I agree that there can be a problem when we wish to do 4.4.2 if we delete the hotfix branch
>
> may be we should use git-flow support instead of hotfix which doesn’t delete the branch
> http://stackoverflow.com/a/16866118/201514
>
> ~Rajani
>
>
>
> On 25-Jul-2014, at 12:31 pm, Daan Hoogland<da...@gmail.com>  wrote:
>
>> Rightful question Erik,
>>
>> Rajani mentioned that release branches will be deleted. This will only
>> happen once the release is no longer supported. Any hotfix branch will
>> still have to merged on that (and master possibly) until we stop
>> supporting that branch.
>>
>> On the other hand you can branch from any commit.
>>
>> btw 4.4.1 is a bad example of you as we will still maintain that
>> without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.
>>
>> On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber<te...@gmail.com>  wrote:
>>> This is out of my git league, but how do you handle minor versions that way?
>>>
>>> Assuming 4.8.0 is the latest stable release and HEAD on master.
>>>
>>> Then you want to release 4.4.1.
>>>
>>> First of all can you develop bugfixes for 4.4 along the way, when both
>>> develop and master HEAD might be hugely different?
>>>
>>> Second, can you commit  behind HEAD? You don't want the 4.4.1 release
>>> instead of 4.8.0 to be HEAD
>>>
>>> Someone might have good solutions to this, but if not I would propose to
>>> keep the release branches for future bugfixes.
>>>
>>> Erik
>>> 25. juli 2014 06:02 skrev "Rajani Karuturi"<Ra...@citrix.com>
>>> følgende:
>>>
>>>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski<mi...@solidfire.com>
>>>> wrote:
>>>>
>>>>> I believe I agree with these steps.
>>>>>
>>>>> A couple questions:
>>>>>
>>>>> Is 'master' simply always going to be equal to what's the most recent
>>>>> version of the code that's in production?
>>>> I think so. master will always be at the latest release and all the
>>>> previous releases properly tagged. The release branches would be deleted
>>>> once release is done.
>>>>
>>>>> Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
>>>>> into RELEASE-4.5?
>>>>>
>>>> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
>>>> should be done on the 4.5 branch.
>>>>
>>>>
>>>>
>>>> ~Rajani
>>>>
>>>>
>>>>> On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi<
>>>>> Rajani.Karuturi@citrix.com>  wrote:
>>>>>
>>>>>> Hi Daan,
>>>>>> here is what i propose:
>>>>>>
>>>>>> 1. rename 'master' to 'develop’
>>>>>> 2. branch a new 'master' from '4.4’
>>>>>> 3. branch 'RELEASE-4.5' from the develop
>>>>>> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>>>>>>
>>>>>> RELEASE-4.6 branch should be off develop as all the feature branches
>>>> would
>>>>>> be merged there before freeze for 4.6 and would be merged to master when
>>>>>> the release is voted.
>>>>>>
>>>>>> The other question I have is in the step:4. how are we going to manage
>>>>>> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is
>>>> done)
>>>>>> ~Rajani
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 24-Jul-2014, at 11:52 am, Daan Hoogland<da...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Mike, Rajani,
>>>>>>>
>>>>>>> Sebastien's point was that the current 4.4 is the closest we have to a
>>>>>>> releasable branch. I don't mind enting on master but it will require
>>>>>>> more fixing. In general all of this will require some RM work of all
>>>>>>> committers. Please ammend my little proposal if you will.
>>>>>>>
>>>>>>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
>>>>>>> <Ra...@citrix.com>  wrote:
>>>>>>>> I agree with mike. I think we should start 4.5 from where master is
>>>> now
>>>>>>>> Also create a develop branch from master and continue future work for
>>>>>> 4.6 there.
>>>>>>>> I am not clear on how the release branches are going to be maintained.
>>>>>>>> Are we saying we would create 4.5-RELEASE branch which is essentially
>>>>>> same as our current -FORWARD branch and continue cherry-picking?
>>>>>>>> I would prefer merges to cherry-picks.
>>>>>>>> Also, I think we should allow committers to commit to the RELEASE
>>>>>> branch after discussing about it on dev@ and have RM closely monitor
>>>> them.
>>>>>>>> Any commit intended for 4.5 RELEASE should be checked in after
>>>>>> discussion in the 4.5 Release branch and then merged to develop branch.
>>>>>>>>
>>>>>>>> ~Rajani
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski<
>>>>>> mike.tutkowski@solidfire.com>  wrote:
>>>>>>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
>>>> left
>>>>>> off
>>>>>>>>> and then merge features from develop into 4.5.
>>>>>>>>>
>>>>>>>>> Why don't we instead start 4.5 where master is now with the
>>>> assumption
>>>>>> that
>>>>>>>>> since we are past Feature Freeze for 4.5 that master is stable
>>>> enough?
>>>>>>>>>
>>>>>>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland<
>>>>>> daan.hoogland@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> so to start formulate a proposal:
>>>>>>>>>>
>>>>>>>>>> all work shall be done in a new branch (it is advisable to prefix
>>>> your
>>>>>>>>>> branches with your id)
>>>>>>>>>> when working, features will be cherry-picked/merged into the release
>>>>>>>>>> branch they are for and next into master.
>>>>>>>>>> hotfixes will be done in<branchname>-hotfixes
>>>>>>>>>>
>>>>>>>>>> as transition we will
>>>>>>>>>>
>>>>>>>>>> rename 'master' to 'develop'
>>>>>>>>>> branch a new 'master' from '4.4'
>>>>>>>>>> branch '4.5' from the new 'master'
>>>>>>>>>> merge any features from the new 'develop' to '4.5' and 'master'
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen<
>>>> runseb@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen<runseb@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon<
>>>> nate.gordon@appcore.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>> Let me ask the question, why have master be develop and a release
>>>>>>>>>> branch be
>>>>>>>>>>>>> "master"? If we are going to follow gitflow, why not just stick
>>>>>> with
>>>>>>>>>> the
>>>>>>>>>>>>> norm? If master is the development branch, it might not be
>>>> stable.
>>>>>> I
>>>>>>>>>> think
>>>>>>>>>>>>> the goal here is that we have an obvious stable branch. Anyone
>>>>>> could
>>>>>>>>>> come
>>>>>>>>>>>>> check out master and have the latest useable.
>>>>>>>>>>>> I am in favor of following the norm, so ideally master should be
>>>> our
>>>>>>>>>> stable branch (agreed).
>>>>>>>>>>>> The issue is with the transition.
>>>>>>>>>>>>
>>>>>>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
>>>>>> ideally
>>>>>>>>>> we could start a stable branch of this tag and build up bug fix
>>>>>> releases
>>>>>>>>>> all the way to 4.5 from there.
>>>>>>>>>>>> But all features for 4.5 are already in master.
>>>>>>>>>>>>
>>>>>>>>>>>> So if we create a 'develop' branch of master and stabilize
>>>> 'master'
>>>>>>>>>> then develop is now started from a stable tag (4.4.0).
>>>>>>>>>>> *not* started from a stable tag, and merges will be tricky, no ?
>>>>>>>>>>>
>>>>>>>>>>>> So what's the best way to flip ? There is most likely some git
>>>> magic
>>>>>>>>>> that can we do.
>>>>>>>>>>>>
>>>>>>>>>>>> The new git workflow and the transition process need to be part
>>>> of a
>>>>>>>>>> proposal that we get consensus on.
>>>>>>>>>>>> getting there :)
>>>>>>>>>>>>
>>>>>>>>>>>> -seb
>>>>>>>>>>>>
>>>>>>>>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If
>>>>>> you
>>>>>>>>>>>>> completely squash history, you lose a tremendous amount of
>>>> context,
>>>>>>>>>> which I
>>>>>>>>>>>>> use extensively to figure out why a bug is the way it is. Only
>>>>>> knowing
>>>>>>>>>> that
>>>>>>>>>>>>> the branch was merged at a given point in time doesn't give any
>>>>>>>>>> context.
>>>>>>>>>>>>> Seeing the individual commit history of the branch helps to
>>>>>> preserve
>>>>>>>>>> the
>>>>>>>>>>>>> rationale for why the code was written the way it was. In theory
>>>> if
>>>>>>>>>> every
>>>>>>>>>>>>> change starts out as a branch (feature, hotfix, release), then
>>>> why
>>>>>> not
>>>>>>>>>> just
>>>>>>>>>>>>> merge the branch once it is in a good and acceptable state?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I also agree with Mike that this will have to be a transition
>>>> over
>>>>>>>>>> time. It
>>>>>>>>>>>>> will take some time to clean up master to the point where it can
>>>> be
>>>>>>>>>>>>> considered a solid stable branch. Possibly as part of the 4.5
>>>>>> release.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen<
>>>>>> runseb@gmail.com
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland<
>>>>>> daan.hoogland@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sebastien,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It seems we can do what you are calling for is creating a
>>>> branch
>>>>>>>>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
>>>>>>>>>> master,
>>>>>>>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
>>>>>> in a
>>>>>>>>>>>>>>> branch make a fork of that branch and when that fork is working
>>>>>> do a
>>>>>>>>>>>>>>> cherry-pick. The -forward concept is now used for that but it
>>>> is
>>>>>>>>>>>>>>> broken because more then for one piece of work there are
>>>> commits
>>>>>> on
>>>>>>>>>>>>>>> it. This caused me conflicts during the release. Especially
>>>>>> painfull
>>>>>>>>>>>>>>> as not all was intended to get into the release. We can create
>>>>>> this
>>>>>>>>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
>>>>>>>>>> changes.
>>>>>>>>>>>>>> Yes, that's what I am thinking about too, so +1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Our master would become the -develop- in gitflow terms
>>>>>>>>>>>>>> The release branch you mention would become the -master- in
>>>>>> gitflow
>>>>>>>>>> terms
>>>>>>>>>>>>>> If we start now, indeed we can create 'release' from 4.4 release
>>>>>> tag
>>>>>>>>>>>>>> (voted and shipped).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That means that to create 4.5 we will need to merge features
>>>> back
>>>>>> into
>>>>>>>>>>>>>> 'release'. it might be messy because some of those features are
>>>>>>>>>> already in
>>>>>>>>>>>>>> our current master.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But all of this will keep 'release' clean (we can keep track of
>>>>>> bugs
>>>>>>>>>> and
>>>>>>>>>>>>>> features that are in it in CHANGES file etc..)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There is a question of control. Do we allow all committers to
>>>>>> manage
>>>>>>>>>>>>>>> the release? I am for that but can imagine not everybody is.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> At first I would say that only the RM can commit to 'release'.
>>>> As
>>>>>> we
>>>>>>>>>> get
>>>>>>>>>>>>>> the CI in place  we could relax this and allow commits that pass
>>>>>> the
>>>>>>>>>> CI to
>>>>>>>>>>>>>> get into 'release', but right now I would vote for a tighter
>>>>>> control
>>>>>>>>>> of
>>>>>>>>>>>>>> 'release'.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> rule number 1 will be: you are going to do something to the
>>>>>> code, you
>>>>>>>>>>>>>>> start by creating a branch.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> right?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen<
>>>>>>>>>> runseb@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit<
>>>>>> sam.schmit@appcore.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I've been a developer for a handful of years and have had my
>>>>>> share
>>>>>>>>>> of
>>>>>>>>>>>>>>>>> experience with different version control systems.  I've used
>>>>>> (for
>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Each of these solutions offers their own unique set of
>>>>>> features,
>>>>>>>>>>>>>> strengths
>>>>>>>>>>>>>>>>> and weaknesses.  As there are so many systems that are good
>>>> at
>>>>>>>>>> specific
>>>>>>>>>>>>>>>>> things, it seems best to use the features that the chosen
>>>>>> system is
>>>>>>>>>>>>>> best at.
>>>>>>>>>>>>>>>>> Git is great at branching, merging and using that structure
>>>> to
>>>>>>>>>>>>>> maintain and
>>>>>>>>>>>>>>>>> control how changes get into the primary branches.  Git tools
>>>>>> even
>>>>>>>>>> make
>>>>>>>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
>>>>>>>>>> branching
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to
>>>>>> NOT
>>>>>>>>>> make
>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>> of these built-in capabilities.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In addition to that, I know that the current method of change
>>>>>>>>>>>>>> management is
>>>>>>>>>>>>>>>>> incredibly frustrating to work with, and works directly
>>>>>> against the
>>>>>>>>>>>>>> way a
>>>>>>>>>>>>>>>>> typical Git user would expect it to be structured.  I should
>>>>>> NEVER
>>>>>>>>>> have
>>>>>>>>>>>>>>>>> problem compiling and running something on master.  I should
>>>>>> not
>>>>>>>>>> have
>>>>>>>>>>>>>>>>> problems building anything on a release branch.  A
>>>>>> feature/bugfix
>>>>>>>>>>>>>> branch is
>>>>>>>>>>>>>>>>> where things can be, and often are, broken or unstable.
>>>> There
>>>>>> have
>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>> many times working in Cloudstack where I've had to search
>>>> for a
>>>>>>>>>> stable
>>>>>>>>>>>>>>>>> revision on master, and that's just plain wrong.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I do realize that having this many developers working on so
>>>>>> many
>>>>>>>>>>>>>> features
>>>>>>>>>>>>>>>>> and bugfixes will result in a large number of branches.  I
>>>>>> don't
>>>>>>>>>>>>>> believe
>>>>>>>>>>>>>>>>> this is a good argument against using a branching method,
>>>>>> though -
>>>>>>>>>> I
>>>>>>>>>>>>>>>>> believe that the current system is even more confusing and
>>>>>>>>>> difficult
>>>>>>>>>>>>>> to use.
>>>>>>>>>>>>>>>>> I could pontificate on change management quite a bit more,
>>>> but
>>>>>> my
>>>>>>>>>>>>>> opinion
>>>>>>>>>>>>>>>>> in summary would basically be:  use Git the way it was meant
>>>>>> to be
>>>>>>>>>>>>>> used,
>>>>>>>>>>>>>>>>> and things will be better.  Just my two cents.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sam
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sam, I think we are in agreement (at least with folks who
>>>>>> responded
>>>>>>>>>> to
>>>>>>>>>>>>>> this thread).
>>>>>>>>>>>>>>>> Or maybe I am not reading your mail right and you don't agree
>>>>>> with
>>>>>>>>>> Leo ?
>>>>>>>>>>>>>>>> My own take and reason for calling for a change we are
>>>> currently
>>>>>>>>>> doing
>>>>>>>>>>>>>> things is mostly due to the way we release.
>>>>>>>>>>>>>>>> I would like to see a stable master (and I think we are in
>>>>>> agreement
>>>>>>>>>>>>>> with that).
>>>>>>>>>>>>>>>> That means that development should not happen on master and
>>>> that
>>>>>>>>>> every
>>>>>>>>>>>>>> commit that lands on master should be shippable.
>>>>>>>>>>>>>>>> I personally have no issues with cherry-picking. So I would be
>>>>>> fine
>>>>>>>>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
>>>>>>>>>>>>>>>> The end result is that the next commit on master would still
>>>>>> mean
>>>>>>>>>>>>>> master is shippable/releasable.
>>>>>>>>>>>>>>>> If we agree with this basic concept. The question becomes how
>>>>>> do we
>>>>>>>>>> get
>>>>>>>>>>>>>> there, considering that master is now full of dev work and
>>>>>> potential
>>>>>>>>>> bug.
>>>>>>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
>>>>>> previous
>>>>>>>>>>>>>> release branches.
>>>>>>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our
>>>>>> way
>>>>>>>>>> back,
>>>>>>>>>>>>>> merging the new features that are already in master into the new
>>>>>>>>>> master
>>>>>>>>>>>>>> (based on 4.4).
>>>>>>>>>>>>>>>> This could be quite complicated but we need to do it (or
>>>>>> something
>>>>>>>>>> like
>>>>>>>>>>>>>> it).
>>>>>>>>>>>>>>>> To move forward, we should make a proposal to the list and
>>>> call
>>>>>> for
>>>>>>>>>> a
>>>>>>>>>>>>>> vote.
>>>>>>>>>>>>>>>> Any takers to start a wiki page proposing a new git process
>>>> and
>>>>>> how
>>>>>>>>>> we
>>>>>>>>>>>>>> could move to it (transition path) ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Sebastien
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons<
>>>>>>>>>>>>>> LSimons@schubergphilis.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hey folks,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
>>>>>> implement
>>>>>>>>>> this?
>>>>>>>>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
>>>>>>>>>>>>>> committer so
>>>>>>>>>>>>>>>>>> its not that practical for me to volunteer!
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> which might be easier to read.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Similarly, the git-flow scripts that help out with
>>>>>> implementing
>>>>>>>>>> this
>>>>>>>>>>>>>> stuff
>>>>>>>>>>>>>>>>>> https://github.com/nvie/gitflow
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> they also describe the relationship between gitflow and
>>>>>> dealing
>>>>>>>>>> with
>>>>>>>>>>>>>>>>>> multiple remotes
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
>>>>>> support
>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> git-flow
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://www.sourcetreeapp.com/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Because cloudstack currently is full of rebasing and
>>>>>> squashing and
>>>>>>>>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
>>>>>>>>>> visualization
>>>>>>>>>>>>>> tool
>>>>>>>>>>>>>>>>>> (like this or gitk or ...) right now, but it would be
>>>> *great*
>>>>>> to
>>>>>>>>>> have
>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>> forward.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> cheers,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Leo
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen<
>>>>>> runseb@gmail.com
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> I would like to re-start this discussion.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thinking about our release procedure, we clearly need more
>>>>>> tests
>>>>>>>>>> and
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> CI. However it looks like this is going to take some time.
>>>>>>>>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
>>>>>>>>>> agreeing
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just
>>>>>> need to
>>>>>>>>>>>>>> agree on
>>>>>>>>>>>>>>>>>> the git workflow.
>>>>>>>>>>>>>>>>>>> Right now Master is really a development branch, we should
>>>>>> make
>>>>>>>>>> it a
>>>>>>>>>>>>>>>>>> stable branch for production with very few commits.
>>>>>>>>>>>>>>>>>>> This does not mean that we would release less, in contrary
>>>>>> this
>>>>>>>>>> would
>>>>>>>>>>>>>>>>>> ensure that a commit to master means it's a production
>>>>>> release.
>>>>>>>>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back
>>>>>> to
>>>>>>>>>>>>>> Rajani's
>>>>>>>>>>>>>>>>>> point) everything is based on merges.
>>>>>>>>>>>>>>>>>>> I am of the opinion that git flow provides a nice process.
>>>> It
>>>>>>>>>>>>>> basically
>>>>>>>>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
>>>>>>>>>> releases
>>>>>>>>>>>>>>>>>> branches are branched off of that and merged into master and
>>>>>> back
>>>>>>>>>> into
>>>>>>>>>>>>>>>>>> develop….etc
>>>>>>>>>>>>>>>>>>> Please read [1] it's a good read.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> And let's discuss,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> [1]
>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>>>>>>>>> -Sebastien
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi<
>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> There is also the problem of cherry-picking.
>>>>>>>>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches
>>>>>> for
>>>>>>>>>> each
>>>>>>>>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches.
>>>>>> which
>>>>>>>>>> means
>>>>>>>>>>>>>>>>>> distinct commits for each branch and I don’t easily know
>>>>>> which all
>>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>> my commit exists unless I do grep.
>>>>>>>>>>>>>>>>>>>> if we follow merging strategy properly, apart from the
>>>> first
>>>>>>>>>> merge
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> the branch, everything else on top of it should be a
>>>> painless
>>>>>>>>>> merge.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus<sh...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> I think many of the bullet points are what we are
>>>> currently
>>>>>>>>>> doing
>>>>>>>>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to
>>>>>> stay
>>>>>>>>>> in
>>>>>>>>>>>>>> sync
>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> master, no back-merging). I also think that much of what
>>>>>> we do
>>>>>>>>>> now
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>>>>>>>> the way it is simply because there *are* vast changes
>>>>>> between
>>>>>>>>>>>>>> versions.
>>>>>>>>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the
>>>>>> time.
>>>>>>>>>> If
>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine,
>>>> but
>>>>>> some
>>>>>>>>>>>>>> quick
>>>>>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with
>>>>>> having
>>>>>>>>>> single
>>>>>>>>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits
>>>>>> where
>>>>>>>>>> each
>>>>>>>>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to
>>>> remember
>>>>>>>>>> why we
>>>>>>>>>>>>>> went
>>>>>>>>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
>>>>>>>>>> somewhere, but
>>>>>>>>>>>>>>>>>> one of
>>>>>>>>>>>>>>>>>>>>> the nice things it provides is the ability for the
>>>> release
>>>>>>>>>> manager
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> control what changes are made during code freeze while
>>>>>> giving
>>>>>>>>>>>>>> people a
>>>>>>>>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not
>>>> always
>>>>>>>>>>>>>> followed).
>>>>>>>>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have
>>>>>> their
>>>>>>>>>> own
>>>>>>>>>>>>>>>>>> repo and
>>>>>>>>>>>>>>>>>>>>> issue pull requests for bugfixes?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi<
>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
>>>>>>>>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi<
>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a
>>>> empty
>>>>>>>>>>>>>>>>>> merge(merge -s
>>>>>>>>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
>>>>>>>>>> bring in
>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>>>>>>> changes.
>>>>>>>>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a
>>>> major
>>>>>>>>>>>>>> rewrite, we
>>>>>>>>>>>>>>>>>>>>>> could stop merging to that branch and above and make the
>>>>>> fix
>>>>>>>>>>>>>> manually.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski<
>>>>>>>>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com>  wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a
>>>>>> particular fix
>>>>>>>>>>>>>> for an
>>>>>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does
>>>>>> happen.
>>>>>>>>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to
>>>> branch
>>>>>> x"
>>>>>>>>>> in
>>>>>>>>>>>>>> SVN
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
>>>>>>>>>> branch(es).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner<
>>>>>>>>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
>>>>>> versions, or
>>>>>>>>>>>>>> has to
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
>>>>>> changed?
>>>>>>>>>>>>>> Don't
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after
>>>>>> that?
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> Stephen Turner
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
>>>>>> mike.tutkowski@solidfire.com]
>>>>>>>>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
>>>>>>>>>> consider.
>>>>>>>>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be
>>>> error
>>>>>>>>>> prone
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
>>>>>> applicable
>>>>>>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks
>>>> are
>>>>>>>>>>>>>> related.
>>>>>>>>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to
>>>>>> see
>>>>>>>>>> if you
>>>>>>>>>>>>>>>>>>>>>> checked a
>>>>>>>>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In
>>>>>> such a
>>>>>>>>>>>>>>>>>> situation,
>>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
>>>>>> check-in
>>>>>>>>>>>>>> was no
>>>>>>>>>>>>>>>>>>>>>> longer
>>>>>>>>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to
>>>>>> mark
>>>>>>>>>> it as
>>>>>>>>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure
>>>>>> about
>>>>>>>>>> Git).
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi<
>>>>>>>>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>  wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the
>>>>>> *forward
>>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all
>>>>>> releases the
>>>>>>>>>>>>>> commit
>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also,
>>>> as a
>>>>>>>>>>>>>>>>>> contributor, I
>>>>>>>>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
>>>>>>>>>> cleanly
>>>>>>>>>>>>>>>>>> apply on
>>>>>>>>>>>>>>>>>>>>>>>>>> different branches.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is
>>>> what I
>>>>>>>>>>>>>> propose.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major
>>>> release(ex:
>>>>>>>>>> 4.3.x,
>>>>>>>>>>>>>>>>>> 4.4.x,
>>>>>>>>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>>>>>>>>>>>>>> accordingly
>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>>>> the respective branches.
>>>>>>>>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed.
>>>>>> Many
>>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when
>>>> we
>>>>>>>>>>>>>> cherry-pick,
>>>>>>>>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
>>>>>>>>>> change or
>>>>>>>>>>>>>>>>>> fix and
>>>>>>>>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
>>>>>> release
>>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They
>>>> should
>>>>>> be
>>>>>>>>>>>>>>>>>> merged(either
>>>>>>>>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
>>>>>>>>>> trackable
>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>>> git branch --contains
>>>>>>>>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
>>>>>> release
>>>>>>>>>>>>>> uptill
>>>>>>>>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches
>>>> master.
>>>>>>>>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next
>>>> time
>>>>>> a
>>>>>>>>>> new
>>>>>>>>>>>>>> commit
>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
>>>>>> master
>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
>>>>>>>>>> proactively
>>>>>>>>>>>>>>>>>> take
>>>>>>>>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
>>>>>> master
>>>>>>>>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
>>>>>> master on
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>>>>>> complete through a merge.
>>>>>>>>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
>>>>>> release
>>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any
>>>> minor
>>>>>>>>>> release)
>>>>>>>>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
>>>>>> information
>>>>>>>>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by<author>;
>>>> reviewed
>>>>>> by
>>>>>>>>>>>>>>>>>>>>>> <committer>
>>>>>>>>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
>>>>>> freeze),
>>>>>>>>>>>>>> any bug
>>>>>>>>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
>>>>>>>>>> release(4.4)
>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
>>>>>> branch.
>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be
>>>> using
>>>>>>>>>> jira
>>>>>>>>>>>>>> vote?)
>>>>>>>>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another
>>>>>> branch
>>>>>>>>>>>>>>>>>>>>>> maintenance.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Ref:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ~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
>>>>>>> *™*
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> *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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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>*™*
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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>*™*
>>>>
>>
>>
>> --
>> Daan
>

--
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: [DISCUSS][PROPOSAL] git workflow

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

24. juli 2014 06:28 skrev "Rajani Karuturi" <Ra...@citrix.com>
følgende:
>
> I agree with mike. I think we should start 4.5 from where master is now
> Also create a develop branch from master and continue future work for 4.6
there.
>
> I am not clear on how the release branches are going to be maintained.
> Are we saying we would create 4.5-RELEASE branch which is essentially
same as our current -FORWARD branch and continue cherry-picking?

After feature freeze or whenever it's decided to finish a release you
create a branch called release-version, e.g. release-4.6.

>From then on 'develop' focus is on 4.7 or whatever the next version is
called.

Whenever something gets merged to release-4.6 it should also get merged to
develop.

> I would prefer merges to cherry-picks.

A lot of the point in this workflow is visibility / traceability, so
merging should really be the way we work

> Also, I think we should allow committers to commit to the RELEASE branch
after discussing about it on dev@ and have RM closely monitor them.

If code is merged instead of cherry-picked it is easier to see / trace what
has happened , and potentially revert.

It is important though that RM's job isn't made much more difficult to
manage .

Erik

> Any commit intended for 4.5 RELEASE should be checked in after discussion
in the 4.5 Release branch and then merged to develop branch.
>
>
> ~Rajani
>
>
>
> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <mi...@solidfire.com>
wrote:
>
> > Per earlier e-mails, I don't think we want to start 4.5 where 4.4 left
off
> > and then merge features from develop into 4.5.
> >
> > Why don't we instead start 4.5 where master is now with the assumption
that
> > since we are past Feature Freeze for 4.5 that master is stable enough?
> >
> >
> > On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <daan.hoogland@gmail.com
>
> > wrote:
> >
> >> so to start formulate a proposal:
> >>
> >> all work shall be done in a new branch (it is advisable to prefix your
> >> branches with your id)
> >> when working, features will be cherry-picked/merged into the release
> >> branch they are for and next into master.
> >> hotfixes will be done in <branchname>-hotfixes
> >>
> >> as transition we will
> >>
> >> rename 'master' to 'develop'
> >> branch a new 'master' from '4.4'
> >> branch '4.5' from the new 'master'
> >> merge any features from the new 'develop' to '4.5' and 'master'
> >>
> >>
> >>
> >> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <ru...@gmail.com>
> >> wrote:
> >>>
> >>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <ru...@gmail.com>
> >> wrote:
> >>>
> >>>>
> >>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com>
> >> wrote:
> >>>>
> >>>>> Let me ask the question, why have master be develop and a release
> >> branch be
> >>>>> "master"? If we are going to follow gitflow, why not just stick with
> >> the
> >>>>> norm? If master is the development branch, it might not be stable. I
> >> think
> >>>>> the goal here is that we have an obvious stable branch. Anyone could
> >> come
> >>>>> check out master and have the latest useable.
> >>>>
> >>>> I am in favor of following the norm, so ideally master should be our
> >> stable branch (agreed).
> >>>>
> >>>> The issue is with the transition.
> >>>>
> >>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
ideally
> >> we could start a stable branch of this tag and build up bug fix
releases
> >> all the way to 4.5 from there.
> >>>>
> >>>> But all features for 4.5 are already in master.
> >>>>
> >>>> So if we create a 'develop' branch of master and stabilize 'master'
> >> then develop is now started from a stable tag (4.4.0).
> >>>>
> >>>
> >>> *not* started from a stable tag, and merges will be tricky, no ?
> >>>
> >>>> So what's the best way to flip ? There is most likely some git magic
> >> that can we do.
> >>>>
> >>>>
> >>>> The new git workflow and the transition process need to be part of a
> >> proposal that we get consensus on.
> >>>>
> >>>> getting there :)
> >>>>
> >>>> -seb
> >>>>
> >>>>>
> >>>>> Also, I'm struggling to understand the benefit of cherry-pick. If
you
> >>>>> completely squash history, you lose a tremendous amount of context,
> >> which I
> >>>>> use extensively to figure out why a bug is the way it is. Only
knowing
> >> that
> >>>>> the branch was merged at a given point in time doesn't give any
> >> context.
> >>>>> Seeing the individual commit history of the branch helps to preserve
> >> the
> >>>>> rationale for why the code was written the way it was. In theory if
> >> every
> >>>>> change starts out as a branch (feature, hotfix, release), then why
not
> >> just
> >>>>> merge the branch once it is in a good and acceptable state?
> >>>>>
> >>>>> I also agree with Mike that this will have to be a transition over
> >> time. It
> >>>>> will take some time to clean up master to the point where it can be
> >>>>> considered a solid stable branch. Possibly as part of the 4.5
release.
> >>>>>
> >>>>>
> >>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
runseb@gmail.com
> >>>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <
daan.hoogland@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Sebastien,
> >>>>>>>
> >>>>>>> It seems we can do what you are calling for is creating a branch
> >>>>>>> called 'release'. We can merge back into that branch from 4.4,
> >> master,
> >>>>>>> 4.3. I would like to see people that want a feature or bug fix in
a
> >>>>>>> branch make a fork of that branch and when that fork is working
do a
> >>>>>>> cherry-pick. The -forward concept is now used for that but it is
> >>>>>>> broken because more then for one piece of work there are commits
on
> >>>>>>> it. This caused me conflicts during the release. Especially
painfull
> >>>>>>> as not all was intended to get into the release. We can create
this
> >>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
> >> changes.
> >>>>>>
> >>>>>> Yes, that's what I am thinking about too, so +1
> >>>>>>
> >>>>>> Our master would become the -develop- in gitflow terms
> >>>>>> The release branch you mention would become the -master- in gitflow
> >> terms
> >>>>>>
> >>>>>> If we start now, indeed we can create 'release' from 4.4 release
tag
> >>>>>> (voted and shipped).
> >>>>>>
> >>>>>> That means that to create 4.5 we will need to merge features back
into
> >>>>>> 'release'. it might be messy because some of those features are
> >> already in
> >>>>>> our current master.
> >>>>>>
> >>>>>> But all of this will keep 'release' clean (we can keep track of
bugs
> >> and
> >>>>>> features that are in it in CHANGES file etc..)
> >>>>>>
> >>>>>>
> >>>>>>> There is a question of control. Do we allow all committers to
manage
> >>>>>>> the release? I am for that but can imagine not everybody is.
> >>>>>>>
> >>>>>>
> >>>>>> At first I would say that only the RM can commit to 'release'. As
we
> >> get
> >>>>>> the CI in place  we could relax this and allow commits that pass
the
> >> CI to
> >>>>>> get into 'release', but right now I would vote for a tighter
control
> >> of
> >>>>>> 'release'.
> >>>>>>
> >>>>>>> rule number 1 will be: you are going to do something to the code,
you
> >>>>>>> start by creating a branch.
> >>>>>>>
> >>>>>>> right?
> >>>>>>>
> >>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
> >> runseb@gmail.com>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hey everyone,
> >>>>>>>>>
> >>>>>>>>> I've been a developer for a handful of years and have had my
share
> >> of
> >>>>>>>>> experience with different version control systems.  I've used
(for
> >>>>>> better
> >>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>>>>>>>
> >>>>>>>>> Each of these solutions offers their own unique set of features,
> >>>>>> strengths
> >>>>>>>>> and weaknesses.  As there are so many systems that are good at
> >> specific
> >>>>>>>>> things, it seems best to use the features that the chosen
system is
> >>>>>> best at.
> >>>>>>>>>
> >>>>>>>>> Git is great at branching, merging and using that structure to
> >>>>>> maintain and
> >>>>>>>>> control how changes get into the primary branches.  Git tools
even
> >> make
> >>>>>>>>> this easy by integrating directly into the "Gitflow" to make
> >> branching
> >>>>>> and
> >>>>>>>>> merging that much easier.  It would seem counter-intuitive to
NOT
> >> make
> >>>>>> use
> >>>>>>>>> of these built-in capabilities.
> >>>>>>>>>
> >>>>>>>>> In addition to that, I know that the current method of change
> >>>>>> management is
> >>>>>>>>> incredibly frustrating to work with, and works directly against
the
> >>>>>> way a
> >>>>>>>>> typical Git user would expect it to be structured.  I should
NEVER
> >> have
> >>>>>>>>> problem compiling and running something on master.  I should not
> >> have
> >>>>>>>>> problems building anything on a release branch.  A
feature/bugfix
> >>>>>> branch is
> >>>>>>>>> where things can be, and often are, broken or unstable.  There
have
> >>>>>> been
> >>>>>>>>> many times working in Cloudstack where I've had to search for a
> >> stable
> >>>>>>>>> revision on master, and that's just plain wrong.
> >>>>>>>>>
> >>>>>>>>> I do realize that having this many developers working on so many
> >>>>>> features
> >>>>>>>>> and bugfixes will result in a large number of branches.  I don't
> >>>>>> believe
> >>>>>>>>> this is a good argument against using a branching method,
though -
> >> I
> >>>>>>>>> believe that the current system is even more confusing and
> >> difficult
> >>>>>> to use.
> >>>>>>>>>
> >>>>>>>>> I could pontificate on change management quite a bit more, but
my
> >>>>>> opinion
> >>>>>>>>> in summary would basically be:  use Git the way it was meant to
be
> >>>>>> used,
> >>>>>>>>> and things will be better.  Just my two cents.
> >>>>>>>>>
> >>>>>>>>> Sam
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Sam, I think we are in agreement (at least with folks who
responded
> >> to
> >>>>>> this thread).
> >>>>>>>> Or maybe I am not reading your mail right and you don't agree
with
> >> Leo ?
> >>>>>>>>
> >>>>>>>> My own take and reason for calling for a change we are currently
> >> doing
> >>>>>> things is mostly due to the way we release.
> >>>>>>>>
> >>>>>>>> I would like to see a stable master (and I think we are in
agreement
> >>>>>> with that).
> >>>>>>>> That means that development should not happen on master and that
> >> every
> >>>>>> commit that lands on master should be shippable.
> >>>>>>>>
> >>>>>>>> I personally have no issues with cherry-picking. So I would be
fine
> >>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
> >>>>>>>> The end result is that the next commit on master would still mean
> >>>>>> master is shippable/releasable.
> >>>>>>>>
> >>>>>>>> If we agree with this basic concept. The question becomes how do
we
> >> get
> >>>>>> there, considering that master is now full of dev work and
potential
> >> bug.
> >>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
previous
> >>>>>> release branches.
> >>>>>>>>
> >>>>>>>> Ideally, I would like to see master becomes 4.4. And work our way
> >> back,
> >>>>>> merging the new features that are already in master into the new
> >> master
> >>>>>> (based on 4.4).
> >>>>>>>> This could be quite complicated but we need to do it (or
something
> >> like
> >>>>>> it).
> >>>>>>>>
> >>>>>>>> To move forward, we should make a proposal to the list and call
for
> >> a
> >>>>>> vote.
> >>>>>>>>
> >>>>>>>> Any takers to start a wiki page proposing a new git process and
how
> >> we
> >>>>>> could move to it (transition path) ?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -Sebastien
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
> >>>>>> LSimons@schubergphilis.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hey folks,
> >>>>>>>>>>
> >>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and implement
> >> this?
> >>>>>>>>>>
> >>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
> >>>>>> committer so
> >>>>>>>>>> its not that practical for me to volunteer!
> >>>>>>>>>>
> >>>>>>>>>> I wanted to point out atlassian’s description of gitflow
> >>>>>>>>>>
> >>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
> >>>>>>>>>>
> >>>>>>>>>> which might be easier to read.
> >>>>>>>>>>
> >>>>>>>>>> Similarly, the git-flow scripts that help out with implementing
> >> this
> >>>>>> stuff
> >>>>>>>>>>
> >>>>>>>>>> https://github.com/nvie/gitflow
> >>>>>>>>>>
> >>>>>>>>>> they also describe the relationship between gitflow and dealing
> >> with
> >>>>>>>>>> multiple remotes
> >>>>>>>>>>
> >>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
> >>>>>>>>>>
> >>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
support
> >> for
> >>>>>>>>>> git-flow
> >>>>>>>>>>
> >>>>>>>>>> http://www.sourcetreeapp.com/
> >>>>>>>>>>
> >>>>>>>>>> Because cloudstack currently is full of rebasing and squashing
and
> >>>>>>>>>> cherry-picking, you get very little benefit from a tree
> >> visualization
> >>>>>> tool
> >>>>>>>>>> (like this or gitk or ...) right now, but it would be *great*
to
> >> have
> >>>>>> going
> >>>>>>>>>> forward.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> cheers,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Leo
> >>>>>>>>>>
> >>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
runseb@gmail.com
> >>>
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I would like to re-start this discussion.
> >>>>>>>>>>>
> >>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
> >>>>>>>>>>>
> >>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>
> >>>>>>>>>>> Thinking about our release procedure, we clearly need more
tests
> >> and
> >>>>>> a
> >>>>>>>>>> CI. However it looks like this is going to take some time.
> >>>>>>>>>>>
> >>>>>>>>>>> In the meantime I think there is nothing preventing us from
> >> agreeing
> >>>>>> to
> >>>>>>>>>> 'git practices', we don't need tests or new infra, we just
need to
> >>>>>> agree on
> >>>>>>>>>> the git workflow.
> >>>>>>>>>>>
> >>>>>>>>>>> Right now Master is really a development branch, we should
make
> >> it a
> >>>>>>>>>> stable branch for production with very few commits.
> >>>>>>>>>>> This does not mean that we would release less, in contrary
this
> >> would
> >>>>>>>>>> ensure that a commit to master means it's a production release.
> >>>>>>>>>>>
> >>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back to
> >>>>>> Rajani's
> >>>>>>>>>> point) everything is based on merges.
> >>>>>>>>>>>
> >>>>>>>>>>> I am of the opinion that git flow provides a nice process. It
> >>>>>> basically
> >>>>>>>>>> freezes master. Development happens in a 'develop' branch,
> >> releases
> >>>>>>>>>> branches are branched off of that and merged into master and
back
> >> into
> >>>>>>>>>> develop….etc
> >>>>>>>>>>>
> >>>>>>>>>>> Please read [1] it's a good read.
> >>>>>>>>>>>
> >>>>>>>>>>> And let's discuss,
> >>>>>>>>>>>
> >>>>>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>
> >>>>>>>>>>> -Sebastien
> >>>>>>>>>>>
> >>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
> >>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> There is also the problem of cherry-picking.
> >>>>>>>>>>>> As a contributor, I always endup creating multiple patches
for
> >> each
> >>>>>>>>>> branch as they don’t cleanly apply on the upward branches.
which
> >> means
> >>>>>>>>>> distinct commits for each branch and I don’t easily know which
all
> >>>>>> branches
> >>>>>>>>>> my commit exists unless I do grep.
> >>>>>>>>>>>> if we follow merging strategy properly, apart from the first
> >> merge
> >>>>>> of
> >>>>>>>>>> the branch, everything else on top of it should be a painless
> >> merge.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
> >> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I think many of the bullet points are what we are currently
> >> doing
> >>>>>>>>>>>>> (guidelines for commit comments, feature branches need to
stay
> >> in
> >>>>>> sync
> >>>>>>>>>> with
> >>>>>>>>>>>>> master, no back-merging). I also think that much of what we
do
> >> now
> >>>>>> is
> >>>>>>>>>> done
> >>>>>>>>>>>>> the way it is simply because there *are* vast changes
between
> >>>>>> versions.
> >>>>>>>>>>>>> Classes are getting shuffled around and changed all the
time.
> >> If
> >>>>>> its
> >>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine, but
some
> >>>>>> quick
> >>>>>>>>>> tests
> >>>>>>>>>>>>> seem to indicate that this will be messy getting started.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with having
> >> single
> >>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits
where
> >> each
> >>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember
> >> why we
> >>>>>> went
> >>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
> >> somewhere, but
> >>>>>>>>>> one of
> >>>>>>>>>>>>> the nice things it provides is the ability for the release
> >> manager
> >>>>>> to
> >>>>>>>>>>>>> control what changes are made during code freeze while
giving
> >>>>>> people a
> >>>>>>>>>>>>> place to stage fixes (though admittedly this is not always
> >>>>>> followed).
> >>>>>>>>>>>>> Without -forward, would the flow be for each dev to have
their
> >> own
> >>>>>>>>>> repo and
> >>>>>>>>>>>>> issue pull requests for bugfixes?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> >>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Any other suggestions/objections/comments??
> >>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> >>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
> >>>>>>>>>> merge(merge -s
> >>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
> >> bring in
> >>>>>> any
> >>>>>>>>>>>>>> changes.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If the branches diverged a lot, for example after a major
> >>>>>> rewrite, we
> >>>>>>>>>>>>>> could stop merging to that branch and above and make the
fix
> >>>>>> manually.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a particular
fix
> >>>>>> for an
> >>>>>>>>>> old
> >>>>>>>>>>>>>>>> release may not apply to newer versions. That does
happen.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to branch
x"
> >> in
> >>>>>> SVN
> >>>>>>>>>> and
> >>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>> you handed it however made sense on the applicable
> >> branch(es).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>>>>>>>>>>>>> Stephen.Turner@citrix.com>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
versions, or
> >>>>>> has to
> >>>>>>>>>> be
> >>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
changed?
> >>>>>> Don't
> >>>>>>>>>> the
> >>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after
that?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>> Stephen Turner
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
mike.tutkowski@solidfire.com]
> >>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
> >>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
> >>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I think this flow is something we should seriously
> >> consider.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be error
> >> prone
> >>>>>> in
> >>>>>>>>>> that
> >>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
applicable
> >>>>>>>>>> branches
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
> >>>>>> related.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to see
> >> if you
> >>>>>>>>>>>>>> checked a
> >>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In
such a
> >>>>>>>>>> situation,
> >>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
check-in
> >>>>>> was no
> >>>>>>>>>>>>>> longer
> >>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to
mark
> >> it as
> >>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure
about
> >> Git).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the *forward
> >>>>>> branches
> >>>>>>>>>> and
> >>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all releases
the
> >>>>>> commit
> >>>>>>>>>> has
> >>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
> >>>>>>>>>> contributor, I
> >>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
> >> cleanly
> >>>>>>>>>> apply on
> >>>>>>>>>>>>>>>>>> different branches.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
> >>>>>> propose.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 1.  There should be branch for every major release(ex:
> >> 4.3.x,
> >>>>>>>>>> 4.4.x,
> >>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
> >>>>>> accordingly
> >>>>>>>>>> on
> >>>>>>>>>>>>>>>>>> the respective branches.
> >>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed.
Many
> >>>>>> branches
> >>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
> >>>>>> cherry-pick,
> >>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
> >> change or
> >>>>>>>>>> fix and
> >>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
release
> >>>>>> branches
> >>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should
be
> >>>>>>>>>> merged(either
> >>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
> >> trackable
> >>>>>>>>>> with
> >>>>>>>>>>>>>>>>>> git branch --contains
> >>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
release
> >>>>>> uptill
> >>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
> >>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> >>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time a
> >> new
> >>>>>> commit
> >>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>> done this will also get merged.
> >>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
master
> >> to
> >>>>>>>>>> feature
> >>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
> >> proactively
> >>>>>>>>>> take
> >>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
master
> >>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
master on
> >>>>>> code
> >>>>>>>>>>>>>>>>>> complete through a merge.
> >>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
release
> >>>>>> branches
> >>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor
> >> release)
> >>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
information
> >>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed
by
> >>>>>>>>>>>>>> <committer>
> >>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
> >>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
freeze),
> >>>>>> any bug
> >>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
> >> release(4.4)
> >>>>>> only
> >>>>>>>>>> on
> >>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
branch.
> >>>>>> This
> >>>>>>>>>> can be
> >>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be using
> >> jira
> >>>>>> vote?)
> >>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another
branch
> >>>>>>>>>>>>>> maintenance.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Ref:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>
> >> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> ~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>*™*
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> *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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>>
> >>>>> *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.
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> 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: [DISCUSS][PROPOSAL] git workflow

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

I suppose we need a formal VOTE on this?

If so, perhaps Sebastien would like to call it.


On Thu, Jul 24, 2014 at 10:06 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Great. Well, this seems reasonable to me then.
>
> If there are no objections or further comments, when can this be done and
> who would do it?
>
> Thanks
>
>
> On Thu, Jul 24, 2014 at 10:01 PM, Rajani Karuturi <
> Rajani.Karuturi@citrix.com> wrote:
>
>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <mi...@solidfire.com>
>> wrote:
>>
>> > I believe I agree with these steps.
>> >
>> > A couple questions:
>> >
>> > Is 'master' simply always going to be equal to what's the most recent
>> > version of the code that's in production?
>>
>> I think so. master will always be at the latest release and all the
>> previous releases properly tagged. The release branches would be deleted
>> once release is done.
>>
>> >
>> > Also, would 'develop' be for 4.6 code then and 4.5 code would go
>> directly
>> > into RELEASE-4.5?
>> >
>>
>> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
>> should be done on the 4.5 branch.
>>
>>
>>
>> ~Rajani
>>
>>
>> >
>> > On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
>> > Rajani.Karuturi@citrix.com> wrote:
>> >
>> >>
>> >> Hi Daan,
>> >> here is what i propose:
>> >>
>> >> 1. rename 'master' to 'develop’
>> >> 2. branch a new 'master' from '4.4’
>> >> 3. branch 'RELEASE-4.5' from the develop
>> >> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>> >>
>> >> RELEASE-4.6 branch should be off develop as all the feature branches
>> would
>> >> be merged there before freeze for 4.6 and would be merged to master
>> when
>> >> the release is voted.
>> >>
>> >> The other question I have is in the step:4. how are we going to manage
>> >> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is
>> done)
>> >>
>> >> ~Rajani
>> >>
>> >>
>> >>
>> >> On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com>
>> >> wrote:
>> >>
>> >>> Mike, Rajani,
>> >>>
>> >>> Sebastien's point was that the current 4.4 is the closest we have to a
>> >>> releasable branch. I don't mind enting on master but it will require
>> >>> more fixing. In general all of this will require some RM work of all
>> >>> committers. Please ammend my little proposal if you will.
>> >>>
>> >>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
>> >>> <Ra...@citrix.com> wrote:
>> >>>> I agree with mike. I think we should start 4.5 from where master is
>> now
>> >>>> Also create a develop branch from master and continue future work for
>> >> 4.6 there.
>> >>>>
>> >>>> I am not clear on how the release branches are going to be
>> maintained.
>> >>>> Are we saying we would create 4.5-RELEASE branch which is essentially
>> >> same as our current -FORWARD branch and continue cherry-picking?
>> >>>>
>> >>>> I would prefer merges to cherry-picks.
>> >>>> Also, I think we should allow committers to commit to the RELEASE
>> >> branch after discussing about it on dev@ and have RM closely monitor
>> them.
>> >>>> Any commit intended for 4.5 RELEASE should be checked in after
>> >> discussion in the 4.5 Release branch and then merged to develop branch.
>> >>>>
>> >>>>
>> >>>> ~Rajani
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
>> >> mike.tutkowski@solidfire.com> wrote:
>> >>>>
>> >>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
>> left
>> >> off
>> >>>>> and then merge features from develop into 4.5.
>> >>>>>
>> >>>>> Why don't we instead start 4.5 where master is now with the
>> assumption
>> >> that
>> >>>>> since we are past Feature Freeze for 4.5 that master is stable
>> enough?
>> >>>>>
>> >>>>>
>> >>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
>> >> daan.hoogland@gmail.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> so to start formulate a proposal:
>> >>>>>>
>> >>>>>> all work shall be done in a new branch (it is advisable to prefix
>> your
>> >>>>>> branches with your id)
>> >>>>>> when working, features will be cherry-picked/merged into the
>> release
>> >>>>>> branch they are for and next into master.
>> >>>>>> hotfixes will be done in <branchname>-hotfixes
>> >>>>>>
>> >>>>>> as transition we will
>> >>>>>>
>> >>>>>> rename 'master' to 'develop'
>> >>>>>> branch a new 'master' from '4.4'
>> >>>>>> branch '4.5' from the new 'master'
>> >>>>>> merge any features from the new 'develop' to '4.5' and 'master'
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <
>> runseb@gmail.com
>> >>>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <
>> runseb@gmail.com>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <
>> nate.gordon@appcore.com>
>> >>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> Let me ask the question, why have master be develop and a
>> release
>> >>>>>> branch be
>> >>>>>>>>> "master"? If we are going to follow gitflow, why not just stick
>> >> with
>> >>>>>> the
>> >>>>>>>>> norm? If master is the development branch, it might not be
>> stable.
>> >> I
>> >>>>>> think
>> >>>>>>>>> the goal here is that we have an obvious stable branch. Anyone
>> >> could
>> >>>>>> come
>> >>>>>>>>> check out master and have the latest useable.
>> >>>>>>>>
>> >>>>>>>> I am in favor of following the norm, so ideally master should be
>> our
>> >>>>>> stable branch (agreed).
>> >>>>>>>>
>> >>>>>>>> The issue is with the transition.
>> >>>>>>>>
>> >>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
>> >> ideally
>> >>>>>> we could start a stable branch of this tag and build up bug fix
>> >> releases
>> >>>>>> all the way to 4.5 from there.
>> >>>>>>>>
>> >>>>>>>> But all features for 4.5 are already in master.
>> >>>>>>>>
>> >>>>>>>> So if we create a 'develop' branch of master and stabilize
>> 'master'
>> >>>>>> then develop is now started from a stable tag (4.4.0).
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>> *not* started from a stable tag, and merges will be tricky, no ?
>> >>>>>>>
>> >>>>>>>> So what's the best way to flip ? There is most likely some git
>> magic
>> >>>>>> that can we do.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> The new git workflow and the transition process need to be part
>> of a
>> >>>>>> proposal that we get consensus on.
>> >>>>>>>>
>> >>>>>>>> getting there :)
>> >>>>>>>>
>> >>>>>>>> -seb
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Also, I'm struggling to understand the benefit of cherry-pick.
>> If
>> >> you
>> >>>>>>>>> completely squash history, you lose a tremendous amount of
>> context,
>> >>>>>> which I
>> >>>>>>>>> use extensively to figure out why a bug is the way it is. Only
>> >> knowing
>> >>>>>> that
>> >>>>>>>>> the branch was merged at a given point in time doesn't give any
>> >>>>>> context.
>> >>>>>>>>> Seeing the individual commit history of the branch helps to
>> >> preserve
>> >>>>>> the
>> >>>>>>>>> rationale for why the code was written the way it was. In
>> theory if
>> >>>>>> every
>> >>>>>>>>> change starts out as a branch (feature, hotfix, release), then
>> why
>> >> not
>> >>>>>> just
>> >>>>>>>>> merge the branch once it is in a good and acceptable state?
>> >>>>>>>>>
>> >>>>>>>>> I also agree with Mike that this will have to be a transition
>> over
>> >>>>>> time. It
>> >>>>>>>>> will take some time to clean up master to the point where it
>> can be
>> >>>>>>>>> considered a solid stable branch. Possibly as part of the 4.5
>> >> release.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
>> >> runseb@gmail.com
>> >>>>>>>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <
>> >> daan.hoogland@gmail.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> Sebastien,
>> >>>>>>>>>>>
>> >>>>>>>>>>> It seems we can do what you are calling for is creating a
>> branch
>> >>>>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
>> >>>>>> master,
>> >>>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
>> >> in a
>> >>>>>>>>>>> branch make a fork of that branch and when that fork is
>> working
>> >> do a
>> >>>>>>>>>>> cherry-pick. The -forward concept is now used for that but it
>> is
>> >>>>>>>>>>> broken because more then for one piece of work there are
>> commits
>> >> on
>> >>>>>>>>>>> it. This caused me conflicts during the release. Especially
>> >> painfull
>> >>>>>>>>>>> as not all was intended to get into the release. We can create
>> >> this
>> >>>>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
>> >>>>>> changes.
>> >>>>>>>>>>
>> >>>>>>>>>> Yes, that's what I am thinking about too, so +1
>> >>>>>>>>>>
>> >>>>>>>>>> Our master would become the -develop- in gitflow terms
>> >>>>>>>>>> The release branch you mention would become the -master- in
>> >> gitflow
>> >>>>>> terms
>> >>>>>>>>>>
>> >>>>>>>>>> If we start now, indeed we can create 'release' from 4.4
>> release
>> >> tag
>> >>>>>>>>>> (voted and shipped).
>> >>>>>>>>>>
>> >>>>>>>>>> That means that to create 4.5 we will need to merge features
>> back
>> >> into
>> >>>>>>>>>> 'release'. it might be messy because some of those features are
>> >>>>>> already in
>> >>>>>>>>>> our current master.
>> >>>>>>>>>>
>> >>>>>>>>>> But all of this will keep 'release' clean (we can keep track of
>> >> bugs
>> >>>>>> and
>> >>>>>>>>>> features that are in it in CHANGES file etc..)
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> There is a question of control. Do we allow all committers to
>> >> manage
>> >>>>>>>>>>> the release? I am for that but can imagine not everybody is.
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> At first I would say that only the RM can commit to 'release'.
>> As
>> >> we
>> >>>>>> get
>> >>>>>>>>>> the CI in place  we could relax this and allow commits that
>> pass
>> >> the
>> >>>>>> CI to
>> >>>>>>>>>> get into 'release', but right now I would vote for a tighter
>> >> control
>> >>>>>> of
>> >>>>>>>>>> 'release'.
>> >>>>>>>>>>
>> >>>>>>>>>>> rule number 1 will be: you are going to do something to the
>> >> code, you
>> >>>>>>>>>>> start by creating a branch.
>> >>>>>>>>>>>
>> >>>>>>>>>>> right?
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
>> >>>>>> runseb@gmail.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <
>> >> sam.schmit@appcore.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> Hey everyone,
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I've been a developer for a handful of years and have had my
>> >> share
>> >>>>>> of
>> >>>>>>>>>>>>> experience with different version control systems.  I've
>> used
>> >> (for
>> >>>>>>>>>> better
>> >>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Each of these solutions offers their own unique set of
>> >> features,
>> >>>>>>>>>> strengths
>> >>>>>>>>>>>>> and weaknesses.  As there are so many systems that are good
>> at
>> >>>>>> specific
>> >>>>>>>>>>>>> things, it seems best to use the features that the chosen
>> >> system is
>> >>>>>>>>>> best at.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Git is great at branching, merging and using that structure
>> to
>> >>>>>>>>>> maintain and
>> >>>>>>>>>>>>> control how changes get into the primary branches.  Git
>> tools
>> >> even
>> >>>>>> make
>> >>>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
>> >>>>>> branching
>> >>>>>>>>>> and
>> >>>>>>>>>>>>> merging that much easier.  It would seem counter-intuitive
>> to
>> >> NOT
>> >>>>>> make
>> >>>>>>>>>> use
>> >>>>>>>>>>>>> of these built-in capabilities.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> In addition to that, I know that the current method of
>> change
>> >>>>>>>>>> management is
>> >>>>>>>>>>>>> incredibly frustrating to work with, and works directly
>> >> against the
>> >>>>>>>>>> way a
>> >>>>>>>>>>>>> typical Git user would expect it to be structured.  I should
>> >> NEVER
>> >>>>>> have
>> >>>>>>>>>>>>> problem compiling and running something on master.  I should
>> >> not
>> >>>>>> have
>> >>>>>>>>>>>>> problems building anything on a release branch.  A
>> >> feature/bugfix
>> >>>>>>>>>> branch is
>> >>>>>>>>>>>>> where things can be, and often are, broken or unstable.
>>  There
>> >> have
>> >>>>>>>>>> been
>> >>>>>>>>>>>>> many times working in Cloudstack where I've had to search
>> for a
>> >>>>>> stable
>> >>>>>>>>>>>>> revision on master, and that's just plain wrong.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I do realize that having this many developers working on so
>> >> many
>> >>>>>>>>>> features
>> >>>>>>>>>>>>> and bugfixes will result in a large number of branches.  I
>> >> don't
>> >>>>>>>>>> believe
>> >>>>>>>>>>>>> this is a good argument against using a branching method,
>> >> though -
>> >>>>>> I
>> >>>>>>>>>>>>> believe that the current system is even more confusing and
>> >>>>>> difficult
>> >>>>>>>>>> to use.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I could pontificate on change management quite a bit more,
>> but
>> >> my
>> >>>>>>>>>> opinion
>> >>>>>>>>>>>>> in summary would basically be:  use Git the way it was meant
>> >> to be
>> >>>>>>>>>> used,
>> >>>>>>>>>>>>> and things will be better.  Just my two cents.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Sam
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Sam, I think we are in agreement (at least with folks who
>> >> responded
>> >>>>>> to
>> >>>>>>>>>> this thread).
>> >>>>>>>>>>>> Or maybe I am not reading your mail right and you don't agree
>> >> with
>> >>>>>> Leo ?
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> My own take and reason for calling for a change we are
>> currently
>> >>>>>> doing
>> >>>>>>>>>> things is mostly due to the way we release.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I would like to see a stable master (and I think we are in
>> >> agreement
>> >>>>>>>>>> with that).
>> >>>>>>>>>>>> That means that development should not happen on master and
>> that
>> >>>>>> every
>> >>>>>>>>>> commit that lands on master should be shippable.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I personally have no issues with cherry-picking. So I would
>> be
>> >> fine
>> >>>>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
>> >>>>>>>>>>>> The end result is that the next commit on master would still
>> >> mean
>> >>>>>>>>>> master is shippable/releasable.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> If we agree with this basic concept. The question becomes how
>> >> do we
>> >>>>>> get
>> >>>>>>>>>> there, considering that master is now full of dev work and
>> >> potential
>> >>>>>> bug.
>> >>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
>> >> previous
>> >>>>>>>>>> release branches.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our
>> >> way
>> >>>>>> back,
>> >>>>>>>>>> merging the new features that are already in master into the
>> new
>> >>>>>> master
>> >>>>>>>>>> (based on 4.4).
>> >>>>>>>>>>>> This could be quite complicated but we need to do it (or
>> >> something
>> >>>>>> like
>> >>>>>>>>>> it).
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> To move forward, we should make a proposal to the list and
>> call
>> >> for
>> >>>>>> a
>> >>>>>>>>>> vote.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Any takers to start a wiki page proposing a new git process
>> and
>> >> how
>> >>>>>> we
>> >>>>>>>>>> could move to it (transition path) ?
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> -Sebastien
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>> >>>>>>>>>> LSimons@schubergphilis.com>
>> >>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Hey folks,
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
>> >> implement
>> >>>>>> this?
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not
>> a
>> >>>>>>>>>> committer so
>> >>>>>>>>>>>>>> its not that practical for me to volunteer!
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> which might be easier to read.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Similarly, the git-flow scripts that help out with
>> >> implementing
>> >>>>>> this
>> >>>>>>>>>> stuff
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> https://github.com/nvie/gitflow
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> they also describe the relationship between gitflow and
>> >> dealing
>> >>>>>> with
>> >>>>>>>>>>>>>> multiple remotes
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
>> >> support
>> >>>>>> for
>> >>>>>>>>>>>>>> git-flow
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> http://www.sourcetreeapp.com/
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Because cloudstack currently is full of rebasing and
>> >> squashing and
>> >>>>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
>> >>>>>> visualization
>> >>>>>>>>>> tool
>> >>>>>>>>>>>>>> (like this or gitk or ...) right now, but it would be
>> *great*
>> >> to
>> >>>>>> have
>> >>>>>>>>>> going
>> >>>>>>>>>>>>>> forward.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> cheers,
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Leo
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
>> >> runseb@gmail.com
>> >>>>>>>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I would like to re-start this discussion.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Rajani made some good points and someone mentioned
>> Gitflow:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Thinking about our release procedure, we clearly need more
>> >> tests
>> >>>>>> and
>> >>>>>>>>>> a
>> >>>>>>>>>>>>>> CI. However it looks like this is going to take some time.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> In the meantime I think there is nothing preventing us
>> from
>> >>>>>> agreeing
>> >>>>>>>>>> to
>> >>>>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just
>> >> need to
>> >>>>>>>>>> agree on
>> >>>>>>>>>>>>>> the git workflow.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Right now Master is really a development branch, we should
>> >> make
>> >>>>>> it a
>> >>>>>>>>>>>>>> stable branch for production with very few commits.
>> >>>>>>>>>>>>>>> This does not mean that we would release less, in contrary
>> >> this
>> >>>>>> would
>> >>>>>>>>>>>>>> ensure that a commit to master means it's a production
>> >> release.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets
>> back
>> >> to
>> >>>>>>>>>> Rajani's
>> >>>>>>>>>>>>>> point) everything is based on merges.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I am of the opinion that git flow provides a nice
>> process. It
>> >>>>>>>>>> basically
>> >>>>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
>> >>>>>> releases
>> >>>>>>>>>>>>>> branches are branched off of that and merged into master
>> and
>> >> back
>> >>>>>> into
>> >>>>>>>>>>>>>> develop….etc
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Please read [1] it's a good read.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> And let's discuss,
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> [1]
>> http://nvie.com/posts/a-successful-git-branching-model/
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> -Sebastien
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>> >>>>>>>>>> Rajani.Karuturi@citrix.com>
>> >>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> There is also the problem of cherry-picking.
>> >>>>>>>>>>>>>>>> As a contributor, I always endup creating multiple
>> patches
>> >> for
>> >>>>>> each
>> >>>>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches.
>> >> which
>> >>>>>> means
>> >>>>>>>>>>>>>> distinct commits for each branch and I don’t easily know
>> >> which all
>> >>>>>>>>>> branches
>> >>>>>>>>>>>>>> my commit exists unless I do grep.
>> >>>>>>>>>>>>>>>> if we follow merging strategy properly, apart from the
>> first
>> >>>>>> merge
>> >>>>>>>>>> of
>> >>>>>>>>>>>>>> the branch, everything else on top of it should be a
>> painless
>> >>>>>> merge.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> ~Rajani
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <shadowsor@gmail.com
>> >
>> >>>>>> wrote:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> I think many of the bullet points are what we are
>> currently
>> >>>>>> doing
>> >>>>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need
>> to
>> >> stay
>> >>>>>> in
>> >>>>>>>>>> sync
>> >>>>>>>>>>>>>> with
>> >>>>>>>>>>>>>>>>> master, no back-merging). I also think that much of what
>> >> we do
>> >>>>>> now
>> >>>>>>>>>> is
>> >>>>>>>>>>>>>> done
>> >>>>>>>>>>>>>>>>> the way it is simply because there *are* vast changes
>> >> between
>> >>>>>>>>>> versions.
>> >>>>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the
>> >> time.
>> >>>>>> If
>> >>>>>>>>>> its
>> >>>>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine,
>> but
>> >> some
>> >>>>>>>>>> quick
>> >>>>>>>>>>>>>> tests
>> >>>>>>>>>>>>>>>>> seem to indicate that this will be messy getting
>> started.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with
>> >> having
>> >>>>>> single
>> >>>>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits
>> >> where
>> >>>>>> each
>> >>>>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to
>> remember
>> >>>>>> why we
>> >>>>>>>>>> went
>> >>>>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
>> >>>>>> somewhere, but
>> >>>>>>>>>>>>>> one of
>> >>>>>>>>>>>>>>>>> the nice things it provides is the ability for the
>> release
>> >>>>>> manager
>> >>>>>>>>>> to
>> >>>>>>>>>>>>>>>>> control what changes are made during code freeze while
>> >> giving
>> >>>>>>>>>> people a
>> >>>>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not
>> always
>> >>>>>>>>>> followed).
>> >>>>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have
>> >> their
>> >>>>>> own
>> >>>>>>>>>>>>>> repo and
>> >>>>>>>>>>>>>>>>> issue pull requests for bugfixes?
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>> >>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>> >>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
>> >>>>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> ~Rajani
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>> >>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>> >>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a
>> empty
>> >>>>>>>>>>>>>> merge(merge -s
>> >>>>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will
>> not
>> >>>>>> bring in
>> >>>>>>>>>> any
>> >>>>>>>>>>>>>>>>>> changes.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a
>> major
>> >>>>>>>>>> rewrite, we
>> >>>>>>>>>>>>>>>>>> could stop merging to that branch and above and make
>> the
>> >> fix
>> >>>>>>>>>> manually.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> ~Rajani
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>> >>>>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a
>> >> particular fix
>> >>>>>>>>>> for an
>> >>>>>>>>>>>>>> old
>> >>>>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does
>> >> happen.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to
>> branch
>> >> x"
>> >>>>>> in
>> >>>>>>>>>> SVN
>> >>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>>> then
>> >>>>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
>> >>>>>> branch(es).
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>> >>>>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
>> >>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
>> >> versions, or
>> >>>>>>>>>> has to
>> >>>>>>>>>>>>>> be
>> >>>>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
>> >> changed?
>> >>>>>>>>>> Don't
>> >>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after
>> >> that?
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>>>>>> Stephen Turner
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>> >>>>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
>> >> mike.tutkowski@solidfire.com]
>> >>>>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>> >>>>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>> >>>>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
>> >>>>>> consider.
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be
>> error
>> >>>>>> prone
>> >>>>>>>>>> in
>> >>>>>>>>>>>>>> that
>> >>>>>>>>>>>>>>>>>> it's
>> >>>>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
>> >> applicable
>> >>>>>>>>>>>>>> branches
>> >>>>>>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks
>> are
>> >>>>>>>>>> related.
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to
>> >> see
>> >>>>>> if you
>> >>>>>>>>>>>>>>>>>> checked a
>> >>>>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In
>> >> such a
>> >>>>>>>>>>>>>> situation,
>> >>>>>>>>>>>>>>>>>> you
>> >>>>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
>> >> check-in
>> >>>>>>>>>> was no
>> >>>>>>>>>>>>>>>>>> longer
>> >>>>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to
>> >> mark
>> >>>>>> it as
>> >>>>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure
>> >> about
>> >>>>>> Git).
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>> >>>>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Hi all,
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the
>> >> *forward
>> >>>>>>>>>> branches
>> >>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all
>> >> releases the
>> >>>>>>>>>> commit
>> >>>>>>>>>>>>>> has
>> >>>>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also,
>> as a
>> >>>>>>>>>>>>>> contributor, I
>> >>>>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it
>> doesn’t
>> >>>>>> cleanly
>> >>>>>>>>>>>>>> apply on
>> >>>>>>>>>>>>>>>>>>>>>> different branches.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is
>> what I
>> >>>>>>>>>> propose.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major
>> release(ex:
>> >>>>>> 4.3.x,
>> >>>>>>>>>>>>>> 4.4.x,
>> >>>>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be
>> tagged
>> >>>>>>>>>> accordingly
>> >>>>>>>>>>>>>> on
>> >>>>>>>>>>>>>>>>>>>>>> the respective branches.
>> >>>>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed.
>> >> Many
>> >>>>>>>>>> branches
>> >>>>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>> >>>>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when
>> we
>> >>>>>>>>>> cherry-pick,
>> >>>>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the
>> same
>> >>>>>> change or
>> >>>>>>>>>>>>>> fix and
>> >>>>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>> >>>>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
>> >> release
>> >>>>>>>>>> branches
>> >>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They
>> should
>> >> be
>> >>>>>>>>>>>>>> merged(either
>> >>>>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and
>> easily
>> >>>>>> trackable
>> >>>>>>>>>>>>>> with
>> >>>>>>>>>>>>>>>>>>>>>> git branch --contains
>> >>>>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
>> >> release
>> >>>>>>>>>> uptill
>> >>>>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches
>> master.
>> >>>>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>> >>>>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>> >>>>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next
>> time
>> >> a
>> >>>>>> new
>> >>>>>>>>>> commit
>> >>>>>>>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>>>>>> done this will also get merged.
>> >>>>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
>> >> master
>> >>>>>> to
>> >>>>>>>>>>>>>> feature
>> >>>>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
>> >>>>>> proactively
>> >>>>>>>>>>>>>> take
>> >>>>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
>> >> master
>> >>>>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
>> >> master on
>> >>>>>>>>>> code
>> >>>>>>>>>>>>>>>>>>>>>> complete through a merge.
>> >>>>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
>> >> release
>> >>>>>>>>>> branches
>> >>>>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any
>> minor
>> >>>>>> release)
>> >>>>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
>> >> information
>> >>>>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>;
>> reviewed
>> >> by
>> >>>>>>>>>>>>>>>>>> <committer>
>> >>>>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>> >>>>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
>> >> freeze),
>> >>>>>>>>>> any bug
>> >>>>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
>> >>>>>> release(4.4)
>> >>>>>>>>>> only
>> >>>>>>>>>>>>>> on
>> >>>>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
>> >> branch.
>> >>>>>>>>>> This
>> >>>>>>>>>>>>>> can be
>> >>>>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be
>> using
>> >>>>>> jira
>> >>>>>>>>>> vote?)
>> >>>>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another
>> >> branch
>> >>>>>>>>>>>>>>>>>> maintenance.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Ref:
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>> >>>>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> ~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
>> >>> *™*
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>>>>> *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
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> *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.
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> 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>*™*
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> 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>*™*
>>
>>
>
>
> --
> *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>*™*
>



-- 
*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: [DISCUSS][PROPOSAL] git workflow

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

Great. Well, this seems reasonable to me then.

If there are no objections or further comments, when can this be done and
who would do it?

Thanks


On Thu, Jul 24, 2014 at 10:01 PM, Rajani Karuturi <
Rajani.Karuturi@citrix.com> wrote:

> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <mi...@solidfire.com>
> wrote:
>
> > I believe I agree with these steps.
> >
> > A couple questions:
> >
> > Is 'master' simply always going to be equal to what's the most recent
> > version of the code that's in production?
>
> I think so. master will always be at the latest release and all the
> previous releases properly tagged. The release branches would be deleted
> once release is done.
>
> >
> > Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
> > into RELEASE-4.5?
> >
>
> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
> should be done on the 4.5 branch.
>
>
>
> ~Rajani
>
>
> >
> > On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
> > Rajani.Karuturi@citrix.com> wrote:
> >
> >>
> >> Hi Daan,
> >> here is what i propose:
> >>
> >> 1. rename 'master' to 'develop’
> >> 2. branch a new 'master' from '4.4’
> >> 3. branch 'RELEASE-4.5' from the develop
> >> 4. merge 'RELEASE-4.5' to master once the release voting is done.
> >>
> >> RELEASE-4.6 branch should be off develop as all the feature branches
> would
> >> be merged there before freeze for 4.6 and would be merged to master when
> >> the release is voted.
> >>
> >> The other question I have is in the step:4. how are we going to manage
> >> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is
> done)
> >>
> >> ~Rajani
> >>
> >>
> >>
> >> On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com>
> >> wrote:
> >>
> >>> Mike, Rajani,
> >>>
> >>> Sebastien's point was that the current 4.4 is the closest we have to a
> >>> releasable branch. I don't mind enting on master but it will require
> >>> more fixing. In general all of this will require some RM work of all
> >>> committers. Please ammend my little proposal if you will.
> >>>
> >>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
> >>> <Ra...@citrix.com> wrote:
> >>>> I agree with mike. I think we should start 4.5 from where master is
> now
> >>>> Also create a develop branch from master and continue future work for
> >> 4.6 there.
> >>>>
> >>>> I am not clear on how the release branches are going to be maintained.
> >>>> Are we saying we would create 4.5-RELEASE branch which is essentially
> >> same as our current -FORWARD branch and continue cherry-picking?
> >>>>
> >>>> I would prefer merges to cherry-picks.
> >>>> Also, I think we should allow committers to commit to the RELEASE
> >> branch after discussing about it on dev@ and have RM closely monitor
> them.
> >>>> Any commit intended for 4.5 RELEASE should be checked in after
> >> discussion in the 4.5 Release branch and then merged to develop branch.
> >>>>
> >>>>
> >>>> ~Rajani
> >>>>
> >>>>
> >>>>
> >>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
> >> mike.tutkowski@solidfire.com> wrote:
> >>>>
> >>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
> left
> >> off
> >>>>> and then merge features from develop into 4.5.
> >>>>>
> >>>>> Why don't we instead start 4.5 where master is now with the
> assumption
> >> that
> >>>>> since we are past Feature Freeze for 4.5 that master is stable
> enough?
> >>>>>
> >>>>>
> >>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
> >> daan.hoogland@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> so to start formulate a proposal:
> >>>>>>
> >>>>>> all work shall be done in a new branch (it is advisable to prefix
> your
> >>>>>> branches with your id)
> >>>>>> when working, features will be cherry-picked/merged into the release
> >>>>>> branch they are for and next into master.
> >>>>>> hotfixes will be done in <branchname>-hotfixes
> >>>>>>
> >>>>>> as transition we will
> >>>>>>
> >>>>>> rename 'master' to 'develop'
> >>>>>> branch a new 'master' from '4.4'
> >>>>>> branch '4.5' from the new 'master'
> >>>>>> merge any features from the new 'develop' to '4.5' and 'master'
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <
> runseb@gmail.com
> >>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <runseb@gmail.com
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <
> nate.gordon@appcore.com>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Let me ask the question, why have master be develop and a release
> >>>>>> branch be
> >>>>>>>>> "master"? If we are going to follow gitflow, why not just stick
> >> with
> >>>>>> the
> >>>>>>>>> norm? If master is the development branch, it might not be
> stable.
> >> I
> >>>>>> think
> >>>>>>>>> the goal here is that we have an obvious stable branch. Anyone
> >> could
> >>>>>> come
> >>>>>>>>> check out master and have the latest useable.
> >>>>>>>>
> >>>>>>>> I am in favor of following the norm, so ideally master should be
> our
> >>>>>> stable branch (agreed).
> >>>>>>>>
> >>>>>>>> The issue is with the transition.
> >>>>>>>>
> >>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
> >> ideally
> >>>>>> we could start a stable branch of this tag and build up bug fix
> >> releases
> >>>>>> all the way to 4.5 from there.
> >>>>>>>>
> >>>>>>>> But all features for 4.5 are already in master.
> >>>>>>>>
> >>>>>>>> So if we create a 'develop' branch of master and stabilize
> 'master'
> >>>>>> then develop is now started from a stable tag (4.4.0).
> >>>>>>>>
> >>>>>>>
> >>>>>>> *not* started from a stable tag, and merges will be tricky, no ?
> >>>>>>>
> >>>>>>>> So what's the best way to flip ? There is most likely some git
> magic
> >>>>>> that can we do.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> The new git workflow and the transition process need to be part
> of a
> >>>>>> proposal that we get consensus on.
> >>>>>>>>
> >>>>>>>> getting there :)
> >>>>>>>>
> >>>>>>>> -seb
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If
> >> you
> >>>>>>>>> completely squash history, you lose a tremendous amount of
> context,
> >>>>>> which I
> >>>>>>>>> use extensively to figure out why a bug is the way it is. Only
> >> knowing
> >>>>>> that
> >>>>>>>>> the branch was merged at a given point in time doesn't give any
> >>>>>> context.
> >>>>>>>>> Seeing the individual commit history of the branch helps to
> >> preserve
> >>>>>> the
> >>>>>>>>> rationale for why the code was written the way it was. In theory
> if
> >>>>>> every
> >>>>>>>>> change starts out as a branch (feature, hotfix, release), then
> why
> >> not
> >>>>>> just
> >>>>>>>>> merge the branch once it is in a good and acceptable state?
> >>>>>>>>>
> >>>>>>>>> I also agree with Mike that this will have to be a transition
> over
> >>>>>> time. It
> >>>>>>>>> will take some time to clean up master to the point where it can
> be
> >>>>>>>>> considered a solid stable branch. Possibly as part of the 4.5
> >> release.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
> >> runseb@gmail.com
> >>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <
> >> daan.hoogland@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Sebastien,
> >>>>>>>>>>>
> >>>>>>>>>>> It seems we can do what you are calling for is creating a
> branch
> >>>>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
> >>>>>> master,
> >>>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
> >> in a
> >>>>>>>>>>> branch make a fork of that branch and when that fork is working
> >> do a
> >>>>>>>>>>> cherry-pick. The -forward concept is now used for that but it
> is
> >>>>>>>>>>> broken because more then for one piece of work there are
> commits
> >> on
> >>>>>>>>>>> it. This caused me conflicts during the release. Especially
> >> painfull
> >>>>>>>>>>> as not all was intended to get into the release. We can create
> >> this
> >>>>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
> >>>>>> changes.
> >>>>>>>>>>
> >>>>>>>>>> Yes, that's what I am thinking about too, so +1
> >>>>>>>>>>
> >>>>>>>>>> Our master would become the -develop- in gitflow terms
> >>>>>>>>>> The release branch you mention would become the -master- in
> >> gitflow
> >>>>>> terms
> >>>>>>>>>>
> >>>>>>>>>> If we start now, indeed we can create 'release' from 4.4 release
> >> tag
> >>>>>>>>>> (voted and shipped).
> >>>>>>>>>>
> >>>>>>>>>> That means that to create 4.5 we will need to merge features
> back
> >> into
> >>>>>>>>>> 'release'. it might be messy because some of those features are
> >>>>>> already in
> >>>>>>>>>> our current master.
> >>>>>>>>>>
> >>>>>>>>>> But all of this will keep 'release' clean (we can keep track of
> >> bugs
> >>>>>> and
> >>>>>>>>>> features that are in it in CHANGES file etc..)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> There is a question of control. Do we allow all committers to
> >> manage
> >>>>>>>>>>> the release? I am for that but can imagine not everybody is.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> At first I would say that only the RM can commit to 'release'.
> As
> >> we
> >>>>>> get
> >>>>>>>>>> the CI in place  we could relax this and allow commits that pass
> >> the
> >>>>>> CI to
> >>>>>>>>>> get into 'release', but right now I would vote for a tighter
> >> control
> >>>>>> of
> >>>>>>>>>> 'release'.
> >>>>>>>>>>
> >>>>>>>>>>> rule number 1 will be: you are going to do something to the
> >> code, you
> >>>>>>>>>>> start by creating a branch.
> >>>>>>>>>>>
> >>>>>>>>>>> right?
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
> >>>>>> runseb@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <
> >> sam.schmit@appcore.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hey everyone,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I've been a developer for a handful of years and have had my
> >> share
> >>>>>> of
> >>>>>>>>>>>>> experience with different version control systems.  I've used
> >> (for
> >>>>>>>>>> better
> >>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Each of these solutions offers their own unique set of
> >> features,
> >>>>>>>>>> strengths
> >>>>>>>>>>>>> and weaknesses.  As there are so many systems that are good
> at
> >>>>>> specific
> >>>>>>>>>>>>> things, it seems best to use the features that the chosen
> >> system is
> >>>>>>>>>> best at.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Git is great at branching, merging and using that structure
> to
> >>>>>>>>>> maintain and
> >>>>>>>>>>>>> control how changes get into the primary branches.  Git tools
> >> even
> >>>>>> make
> >>>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
> >>>>>> branching
> >>>>>>>>>> and
> >>>>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to
> >> NOT
> >>>>>> make
> >>>>>>>>>> use
> >>>>>>>>>>>>> of these built-in capabilities.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In addition to that, I know that the current method of change
> >>>>>>>>>> management is
> >>>>>>>>>>>>> incredibly frustrating to work with, and works directly
> >> against the
> >>>>>>>>>> way a
> >>>>>>>>>>>>> typical Git user would expect it to be structured.  I should
> >> NEVER
> >>>>>> have
> >>>>>>>>>>>>> problem compiling and running something on master.  I should
> >> not
> >>>>>> have
> >>>>>>>>>>>>> problems building anything on a release branch.  A
> >> feature/bugfix
> >>>>>>>>>> branch is
> >>>>>>>>>>>>> where things can be, and often are, broken or unstable.
>  There
> >> have
> >>>>>>>>>> been
> >>>>>>>>>>>>> many times working in Cloudstack where I've had to search
> for a
> >>>>>> stable
> >>>>>>>>>>>>> revision on master, and that's just plain wrong.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I do realize that having this many developers working on so
> >> many
> >>>>>>>>>> features
> >>>>>>>>>>>>> and bugfixes will result in a large number of branches.  I
> >> don't
> >>>>>>>>>> believe
> >>>>>>>>>>>>> this is a good argument against using a branching method,
> >> though -
> >>>>>> I
> >>>>>>>>>>>>> believe that the current system is even more confusing and
> >>>>>> difficult
> >>>>>>>>>> to use.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I could pontificate on change management quite a bit more,
> but
> >> my
> >>>>>>>>>> opinion
> >>>>>>>>>>>>> in summary would basically be:  use Git the way it was meant
> >> to be
> >>>>>>>>>> used,
> >>>>>>>>>>>>> and things will be better.  Just my two cents.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Sam
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Sam, I think we are in agreement (at least with folks who
> >> responded
> >>>>>> to
> >>>>>>>>>> this thread).
> >>>>>>>>>>>> Or maybe I am not reading your mail right and you don't agree
> >> with
> >>>>>> Leo ?
> >>>>>>>>>>>>
> >>>>>>>>>>>> My own take and reason for calling for a change we are
> currently
> >>>>>> doing
> >>>>>>>>>> things is mostly due to the way we release.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would like to see a stable master (and I think we are in
> >> agreement
> >>>>>>>>>> with that).
> >>>>>>>>>>>> That means that development should not happen on master and
> that
> >>>>>> every
> >>>>>>>>>> commit that lands on master should be shippable.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I personally have no issues with cherry-picking. So I would be
> >> fine
> >>>>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
> >>>>>>>>>>>> The end result is that the next commit on master would still
> >> mean
> >>>>>>>>>> master is shippable/releasable.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If we agree with this basic concept. The question becomes how
> >> do we
> >>>>>> get
> >>>>>>>>>> there, considering that master is now full of dev work and
> >> potential
> >>>>>> bug.
> >>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
> >> previous
> >>>>>>>>>> release branches.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our
> >> way
> >>>>>> back,
> >>>>>>>>>> merging the new features that are already in master into the new
> >>>>>> master
> >>>>>>>>>> (based on 4.4).
> >>>>>>>>>>>> This could be quite complicated but we need to do it (or
> >> something
> >>>>>> like
> >>>>>>>>>> it).
> >>>>>>>>>>>>
> >>>>>>>>>>>> To move forward, we should make a proposal to the list and
> call
> >> for
> >>>>>> a
> >>>>>>>>>> vote.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Any takers to start a wiki page proposing a new git process
> and
> >> how
> >>>>>> we
> >>>>>>>>>> could move to it (transition path) ?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> -Sebastien
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
> >>>>>>>>>> LSimons@schubergphilis.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hey folks,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
> >> implement
> >>>>>> this?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
> >>>>>>>>>> committer so
> >>>>>>>>>>>>>> its not that practical for me to volunteer!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> which might be easier to read.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Similarly, the git-flow scripts that help out with
> >> implementing
> >>>>>> this
> >>>>>>>>>> stuff
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> https://github.com/nvie/gitflow
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> they also describe the relationship between gitflow and
> >> dealing
> >>>>>> with
> >>>>>>>>>>>>>> multiple remotes
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
> >> support
> >>>>>> for
> >>>>>>>>>>>>>> git-flow
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> http://www.sourcetreeapp.com/
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Because cloudstack currently is full of rebasing and
> >> squashing and
> >>>>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
> >>>>>> visualization
> >>>>>>>>>> tool
> >>>>>>>>>>>>>> (like this or gitk or ...) right now, but it would be
> *great*
> >> to
> >>>>>> have
> >>>>>>>>>> going
> >>>>>>>>>>>>>> forward.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> cheers,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Leo
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
> >> runseb@gmail.com
> >>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I would like to re-start this discussion.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thinking about our release procedure, we clearly need more
> >> tests
> >>>>>> and
> >>>>>>>>>> a
> >>>>>>>>>>>>>> CI. However it looks like this is going to take some time.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
> >>>>>> agreeing
> >>>>>>>>>> to
> >>>>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just
> >> need to
> >>>>>>>>>> agree on
> >>>>>>>>>>>>>> the git workflow.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Right now Master is really a development branch, we should
> >> make
> >>>>>> it a
> >>>>>>>>>>>>>> stable branch for production with very few commits.
> >>>>>>>>>>>>>>> This does not mean that we would release less, in contrary
> >> this
> >>>>>> would
> >>>>>>>>>>>>>> ensure that a commit to master means it's a production
> >> release.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back
> >> to
> >>>>>>>>>> Rajani's
> >>>>>>>>>>>>>> point) everything is based on merges.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I am of the opinion that git flow provides a nice process.
> It
> >>>>>>>>>> basically
> >>>>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
> >>>>>> releases
> >>>>>>>>>>>>>> branches are branched off of that and merged into master and
> >> back
> >>>>>> into
> >>>>>>>>>>>>>> develop….etc
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Please read [1] it's a good read.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> And let's discuss,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [1]
> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Sebastien
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
> >>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> There is also the problem of cherry-picking.
> >>>>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches
> >> for
> >>>>>> each
> >>>>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches.
> >> which
> >>>>>> means
> >>>>>>>>>>>>>> distinct commits for each branch and I don’t easily know
> >> which all
> >>>>>>>>>> branches
> >>>>>>>>>>>>>> my commit exists unless I do grep.
> >>>>>>>>>>>>>>>> if we follow merging strategy properly, apart from the
> first
> >>>>>> merge
> >>>>>>>>>> of
> >>>>>>>>>>>>>> the branch, everything else on top of it should be a
> painless
> >>>>>> merge.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
> >>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I think many of the bullet points are what we are
> currently
> >>>>>> doing
> >>>>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to
> >> stay
> >>>>>> in
> >>>>>>>>>> sync
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>> master, no back-merging). I also think that much of what
> >> we do
> >>>>>> now
> >>>>>>>>>> is
> >>>>>>>>>>>>>> done
> >>>>>>>>>>>>>>>>> the way it is simply because there *are* vast changes
> >> between
> >>>>>>>>>> versions.
> >>>>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the
> >> time.
> >>>>>> If
> >>>>>>>>>> its
> >>>>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine,
> but
> >> some
> >>>>>>>>>> quick
> >>>>>>>>>>>>>> tests
> >>>>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with
> >> having
> >>>>>> single
> >>>>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits
> >> where
> >>>>>> each
> >>>>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to
> remember
> >>>>>> why we
> >>>>>>>>>> went
> >>>>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
> >>>>>> somewhere, but
> >>>>>>>>>>>>>> one of
> >>>>>>>>>>>>>>>>> the nice things it provides is the ability for the
> release
> >>>>>> manager
> >>>>>>>>>> to
> >>>>>>>>>>>>>>>>> control what changes are made during code freeze while
> >> giving
> >>>>>>>>>> people a
> >>>>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not
> always
> >>>>>>>>>> followed).
> >>>>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have
> >> their
> >>>>>> own
> >>>>>>>>>>>>>> repo and
> >>>>>>>>>>>>>>>>> issue pull requests for bugfixes?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> >>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
> >>>>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> >>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a
> empty
> >>>>>>>>>>>>>> merge(merge -s
> >>>>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
> >>>>>> bring in
> >>>>>>>>>> any
> >>>>>>>>>>>>>>>>>> changes.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a
> major
> >>>>>>>>>> rewrite, we
> >>>>>>>>>>>>>>>>>> could stop merging to that branch and above and make the
> >> fix
> >>>>>>>>>> manually.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>>>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a
> >> particular fix
> >>>>>>>>>> for an
> >>>>>>>>>>>>>> old
> >>>>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does
> >> happen.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to
> branch
> >> x"
> >>>>>> in
> >>>>>>>>>> SVN
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
> >>>>>> branch(es).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>>>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
> >> versions, or
> >>>>>>>>>> has to
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
> >> changed?
> >>>>>>>>>> Don't
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after
> >> that?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>> Stephen Turner
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
> >> mike.tutkowski@solidfire.com]
> >>>>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
> >>>>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
> >>>>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
> >>>>>> consider.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be
> error
> >>>>>> prone
> >>>>>>>>>> in
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
> >> applicable
> >>>>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks
> are
> >>>>>>>>>> related.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to
> >> see
> >>>>>> if you
> >>>>>>>>>>>>>>>>>> checked a
> >>>>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In
> >> such a
> >>>>>>>>>>>>>> situation,
> >>>>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
> >> check-in
> >>>>>>>>>> was no
> >>>>>>>>>>>>>>>>>> longer
> >>>>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to
> >> mark
> >>>>>> it as
> >>>>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure
> >> about
> >>>>>> Git).
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the
> >> *forward
> >>>>>>>>>> branches
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all
> >> releases the
> >>>>>>>>>> commit
> >>>>>>>>>>>>>> has
> >>>>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also,
> as a
> >>>>>>>>>>>>>> contributor, I
> >>>>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
> >>>>>> cleanly
> >>>>>>>>>>>>>> apply on
> >>>>>>>>>>>>>>>>>>>>>> different branches.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is
> what I
> >>>>>>>>>> propose.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major
> release(ex:
> >>>>>> 4.3.x,
> >>>>>>>>>>>>>> 4.4.x,
> >>>>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
> >>>>>>>>>> accordingly
> >>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>> the respective branches.
> >>>>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed.
> >> Many
> >>>>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when
> we
> >>>>>>>>>> cherry-pick,
> >>>>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
> >>>>>> change or
> >>>>>>>>>>>>>> fix and
> >>>>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
> >> release
> >>>>>>>>>> branches
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They
> should
> >> be
> >>>>>>>>>>>>>> merged(either
> >>>>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
> >>>>>> trackable
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>> git branch --contains
> >>>>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
> >> release
> >>>>>>>>>> uptill
> >>>>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches
> master.
> >>>>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> >>>>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next
> time
> >> a
> >>>>>> new
> >>>>>>>>>> commit
> >>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>> done this will also get merged.
> >>>>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
> >> master
> >>>>>> to
> >>>>>>>>>>>>>> feature
> >>>>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
> >>>>>> proactively
> >>>>>>>>>>>>>> take
> >>>>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
> >> master
> >>>>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
> >> master on
> >>>>>>>>>> code
> >>>>>>>>>>>>>>>>>>>>>> complete through a merge.
> >>>>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
> >> release
> >>>>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any
> minor
> >>>>>> release)
> >>>>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
> >> information
> >>>>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>;
> reviewed
> >> by
> >>>>>>>>>>>>>>>>>> <committer>
> >>>>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
> >>>>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
> >> freeze),
> >>>>>>>>>> any bug
> >>>>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
> >>>>>> release(4.4)
> >>>>>>>>>> only
> >>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
> >> branch.
> >>>>>>>>>> This
> >>>>>>>>>>>>>> can be
> >>>>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be
> using
> >>>>>> jira
> >>>>>>>>>> vote?)
> >>>>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another
> >> branch
> >>>>>>>>>>>>>>>>>> maintenance.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Ref:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> ~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
> >>> *™*
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>> *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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> *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.
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> 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>*™*
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> 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>*™*
>
>


-- 
*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: [DISCUSS][PROPOSAL] git workflow

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

I went on and read the comments in
http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html

It contains a big warning on using gitflow that has been between my
lines in this thread all along. Git flow is not going to solve our
problem. It is a discipline that is captured in it that will save us.
Please everybody educate yourselves on the subject. If we are going to
get along as a community we need to get this right. We'll be able to
support old releases and make new ones just like we dream. gitflow
wont give us that by itself.

Daan (sounding desperate and impatient but being eager)

On Fri, Jul 25, 2014 at 9:01 AM, Daan Hoogland <da...@gmail.com> wrote:
> Rightful question Erik,
>
> Rajani mentioned that release branches will be deleted. This will only
> happen once the release is no longer supported. Any hotfix branch will
> still have to merged on that (and master possibly) until we stop
> supporting that branch.
>
> On the other hand you can branch from any commit.
>
> btw 4.4.1 is a bad example of you as we will still maintain that
> without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.
>
> On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber <te...@gmail.com> wrote:
>> This is out of my git league, but how do you handle minor versions that way?
>>
>> Assuming 4.8.0 is the latest stable release and HEAD on master.
>>
>> Then you want to release 4.4.1.
>>
>> First of all can you develop bugfixes for 4.4 along the way, when both
>> develop and master HEAD might be hugely different?
>>
>> Second, can you commit  behind HEAD? You don't want the 4.4.1 release
>> instead of 4.8.0 to be HEAD
>>
>> Someone might have good solutions to this, but if not I would propose to
>> keep the release branches for future bugfixes.
>>
>> Erik
>> 25. juli 2014 06:02 skrev "Rajani Karuturi" <Ra...@citrix.com>
>> følgende:
>>
>>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <mi...@solidfire.com>
>>> wrote:
>>>
>>> > I believe I agree with these steps.
>>> >
>>> > A couple questions:
>>> >
>>> > Is 'master' simply always going to be equal to what's the most recent
>>> > version of the code that's in production?
>>>
>>> I think so. master will always be at the latest release and all the
>>> previous releases properly tagged. The release branches would be deleted
>>> once release is done.
>>>
>>> >
>>> > Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
>>> > into RELEASE-4.5?
>>> >
>>>
>>> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
>>> should be done on the 4.5 branch.
>>>
>>>
>>>
>>> ~Rajani
>>>
>>>
>>> >
>>> > On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
>>> > Rajani.Karuturi@citrix.com> wrote:
>>> >
>>> >>
>>> >> Hi Daan,
>>> >> here is what i propose:
>>> >>
>>> >> 1. rename 'master' to 'develop’
>>> >> 2. branch a new 'master' from '4.4’
>>> >> 3. branch 'RELEASE-4.5' from the develop
>>> >> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>>> >>
>>> >> RELEASE-4.6 branch should be off develop as all the feature branches
>>> would
>>> >> be merged there before freeze for 4.6 and would be merged to master when
>>> >> the release is voted.
>>> >>
>>> >> The other question I have is in the step:4. how are we going to manage
>>> >> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is
>>> done)
>>> >>
>>> >> ~Rajani
>>> >>
>>> >>
>>> >>
>>> >> On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com>
>>> >> wrote:
>>> >>
>>> >>> Mike, Rajani,
>>> >>>
>>> >>> Sebastien's point was that the current 4.4 is the closest we have to a
>>> >>> releasable branch. I don't mind enting on master but it will require
>>> >>> more fixing. In general all of this will require some RM work of all
>>> >>> committers. Please ammend my little proposal if you will.
>>> >>>
>>> >>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
>>> >>> <Ra...@citrix.com> wrote:
>>> >>>> I agree with mike. I think we should start 4.5 from where master is
>>> now
>>> >>>> Also create a develop branch from master and continue future work for
>>> >> 4.6 there.
>>> >>>>
>>> >>>> I am not clear on how the release branches are going to be maintained.
>>> >>>> Are we saying we would create 4.5-RELEASE branch which is essentially
>>> >> same as our current -FORWARD branch and continue cherry-picking?
>>> >>>>
>>> >>>> I would prefer merges to cherry-picks.
>>> >>>> Also, I think we should allow committers to commit to the RELEASE
>>> >> branch after discussing about it on dev@ and have RM closely monitor
>>> them.
>>> >>>> Any commit intended for 4.5 RELEASE should be checked in after
>>> >> discussion in the 4.5 Release branch and then merged to develop branch.
>>> >>>>
>>> >>>>
>>> >>>> ~Rajani
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
>>> >> mike.tutkowski@solidfire.com> wrote:
>>> >>>>
>>> >>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
>>> left
>>> >> off
>>> >>>>> and then merge features from develop into 4.5.
>>> >>>>>
>>> >>>>> Why don't we instead start 4.5 where master is now with the
>>> assumption
>>> >> that
>>> >>>>> since we are past Feature Freeze for 4.5 that master is stable
>>> enough?
>>> >>>>>
>>> >>>>>
>>> >>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
>>> >> daan.hoogland@gmail.com>
>>> >>>>> wrote:
>>> >>>>>
>>> >>>>>> so to start formulate a proposal:
>>> >>>>>>
>>> >>>>>> all work shall be done in a new branch (it is advisable to prefix
>>> your
>>> >>>>>> branches with your id)
>>> >>>>>> when working, features will be cherry-picked/merged into the release
>>> >>>>>> branch they are for and next into master.
>>> >>>>>> hotfixes will be done in <branchname>-hotfixes
>>> >>>>>>
>>> >>>>>> as transition we will
>>> >>>>>>
>>> >>>>>> rename 'master' to 'develop'
>>> >>>>>> branch a new 'master' from '4.4'
>>> >>>>>> branch '4.5' from the new 'master'
>>> >>>>>> merge any features from the new 'develop' to '4.5' and 'master'
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <
>>> runseb@gmail.com
>>> >>>
>>> >>>>>> wrote:
>>> >>>>>>>
>>> >>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <runseb@gmail.com
>>> >
>>> >>>>>> wrote:
>>> >>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <
>>> nate.gordon@appcore.com>
>>> >>>>>> wrote:
>>> >>>>>>>>
>>> >>>>>>>>> Let me ask the question, why have master be develop and a release
>>> >>>>>> branch be
>>> >>>>>>>>> "master"? If we are going to follow gitflow, why not just stick
>>> >> with
>>> >>>>>> the
>>> >>>>>>>>> norm? If master is the development branch, it might not be
>>> stable.
>>> >> I
>>> >>>>>> think
>>> >>>>>>>>> the goal here is that we have an obvious stable branch. Anyone
>>> >> could
>>> >>>>>> come
>>> >>>>>>>>> check out master and have the latest useable.
>>> >>>>>>>>
>>> >>>>>>>> I am in favor of following the norm, so ideally master should be
>>> our
>>> >>>>>> stable branch (agreed).
>>> >>>>>>>>
>>> >>>>>>>> The issue is with the transition.
>>> >>>>>>>>
>>> >>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
>>> >> ideally
>>> >>>>>> we could start a stable branch of this tag and build up bug fix
>>> >> releases
>>> >>>>>> all the way to 4.5 from there.
>>> >>>>>>>>
>>> >>>>>>>> But all features for 4.5 are already in master.
>>> >>>>>>>>
>>> >>>>>>>> So if we create a 'develop' branch of master and stabilize
>>> 'master'
>>> >>>>>> then develop is now started from a stable tag (4.4.0).
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>> *not* started from a stable tag, and merges will be tricky, no ?
>>> >>>>>>>
>>> >>>>>>>> So what's the best way to flip ? There is most likely some git
>>> magic
>>> >>>>>> that can we do.
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> The new git workflow and the transition process need to be part
>>> of a
>>> >>>>>> proposal that we get consensus on.
>>> >>>>>>>>
>>> >>>>>>>> getting there :)
>>> >>>>>>>>
>>> >>>>>>>> -seb
>>> >>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If
>>> >> you
>>> >>>>>>>>> completely squash history, you lose a tremendous amount of
>>> context,
>>> >>>>>> which I
>>> >>>>>>>>> use extensively to figure out why a bug is the way it is. Only
>>> >> knowing
>>> >>>>>> that
>>> >>>>>>>>> the branch was merged at a given point in time doesn't give any
>>> >>>>>> context.
>>> >>>>>>>>> Seeing the individual commit history of the branch helps to
>>> >> preserve
>>> >>>>>> the
>>> >>>>>>>>> rationale for why the code was written the way it was. In theory
>>> if
>>> >>>>>> every
>>> >>>>>>>>> change starts out as a branch (feature, hotfix, release), then
>>> why
>>> >> not
>>> >>>>>> just
>>> >>>>>>>>> merge the branch once it is in a good and acceptable state?
>>> >>>>>>>>>
>>> >>>>>>>>> I also agree with Mike that this will have to be a transition
>>> over
>>> >>>>>> time. It
>>> >>>>>>>>> will take some time to clean up master to the point where it can
>>> be
>>> >>>>>>>>> considered a solid stable branch. Possibly as part of the 4.5
>>> >> release.
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
>>> >> runseb@gmail.com
>>> >>>>>>>
>>> >>>>>>>>> wrote:
>>> >>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <
>>> >> daan.hoogland@gmail.com>
>>> >>>>>>>>>> wrote:
>>> >>>>>>>>>>
>>> >>>>>>>>>>> Sebastien,
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> It seems we can do what you are calling for is creating a
>>> branch
>>> >>>>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
>>> >>>>>> master,
>>> >>>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
>>> >> in a
>>> >>>>>>>>>>> branch make a fork of that branch and when that fork is working
>>> >> do a
>>> >>>>>>>>>>> cherry-pick. The -forward concept is now used for that but it
>>> is
>>> >>>>>>>>>>> broken because more then for one piece of work there are
>>> commits
>>> >> on
>>> >>>>>>>>>>> it. This caused me conflicts during the release. Especially
>>> >> painfull
>>> >>>>>>>>>>> as not all was intended to get into the release. We can create
>>> >> this
>>> >>>>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
>>> >>>>>> changes.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Yes, that's what I am thinking about too, so +1
>>> >>>>>>>>>>
>>> >>>>>>>>>> Our master would become the -develop- in gitflow terms
>>> >>>>>>>>>> The release branch you mention would become the -master- in
>>> >> gitflow
>>> >>>>>> terms
>>> >>>>>>>>>>
>>> >>>>>>>>>> If we start now, indeed we can create 'release' from 4.4 release
>>> >> tag
>>> >>>>>>>>>> (voted and shipped).
>>> >>>>>>>>>>
>>> >>>>>>>>>> That means that to create 4.5 we will need to merge features
>>> back
>>> >> into
>>> >>>>>>>>>> 'release'. it might be messy because some of those features are
>>> >>>>>> already in
>>> >>>>>>>>>> our current master.
>>> >>>>>>>>>>
>>> >>>>>>>>>> But all of this will keep 'release' clean (we can keep track of
>>> >> bugs
>>> >>>>>> and
>>> >>>>>>>>>> features that are in it in CHANGES file etc..)
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>> There is a question of control. Do we allow all committers to
>>> >> manage
>>> >>>>>>>>>>> the release? I am for that but can imagine not everybody is.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> At first I would say that only the RM can commit to 'release'.
>>> As
>>> >> we
>>> >>>>>> get
>>> >>>>>>>>>> the CI in place  we could relax this and allow commits that pass
>>> >> the
>>> >>>>>> CI to
>>> >>>>>>>>>> get into 'release', but right now I would vote for a tighter
>>> >> control
>>> >>>>>> of
>>> >>>>>>>>>> 'release'.
>>> >>>>>>>>>>
>>> >>>>>>>>>>> rule number 1 will be: you are going to do something to the
>>> >> code, you
>>> >>>>>>>>>>> start by creating a branch.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> right?
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
>>> >>>>>> runseb@gmail.com>
>>> >>>>>>>>>> wrote:
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <
>>> >> sam.schmit@appcore.com>
>>> >>>>>>>>>> wrote:
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>> Hey everyone,
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> I've been a developer for a handful of years and have had my
>>> >> share
>>> >>>>>> of
>>> >>>>>>>>>>>>> experience with different version control systems.  I've used
>>> >> (for
>>> >>>>>>>>>> better
>>> >>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Each of these solutions offers their own unique set of
>>> >> features,
>>> >>>>>>>>>> strengths
>>> >>>>>>>>>>>>> and weaknesses.  As there are so many systems that are good
>>> at
>>> >>>>>> specific
>>> >>>>>>>>>>>>> things, it seems best to use the features that the chosen
>>> >> system is
>>> >>>>>>>>>> best at.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Git is great at branching, merging and using that structure
>>> to
>>> >>>>>>>>>> maintain and
>>> >>>>>>>>>>>>> control how changes get into the primary branches.  Git tools
>>> >> even
>>> >>>>>> make
>>> >>>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
>>> >>>>>> branching
>>> >>>>>>>>>> and
>>> >>>>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to
>>> >> NOT
>>> >>>>>> make
>>> >>>>>>>>>> use
>>> >>>>>>>>>>>>> of these built-in capabilities.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> In addition to that, I know that the current method of change
>>> >>>>>>>>>> management is
>>> >>>>>>>>>>>>> incredibly frustrating to work with, and works directly
>>> >> against the
>>> >>>>>>>>>> way a
>>> >>>>>>>>>>>>> typical Git user would expect it to be structured.  I should
>>> >> NEVER
>>> >>>>>> have
>>> >>>>>>>>>>>>> problem compiling and running something on master.  I should
>>> >> not
>>> >>>>>> have
>>> >>>>>>>>>>>>> problems building anything on a release branch.  A
>>> >> feature/bugfix
>>> >>>>>>>>>> branch is
>>> >>>>>>>>>>>>> where things can be, and often are, broken or unstable.
>>>  There
>>> >> have
>>> >>>>>>>>>> been
>>> >>>>>>>>>>>>> many times working in Cloudstack where I've had to search
>>> for a
>>> >>>>>> stable
>>> >>>>>>>>>>>>> revision on master, and that's just plain wrong.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> I do realize that having this many developers working on so
>>> >> many
>>> >>>>>>>>>> features
>>> >>>>>>>>>>>>> and bugfixes will result in a large number of branches.  I
>>> >> don't
>>> >>>>>>>>>> believe
>>> >>>>>>>>>>>>> this is a good argument against using a branching method,
>>> >> though -
>>> >>>>>> I
>>> >>>>>>>>>>>>> believe that the current system is even more confusing and
>>> >>>>>> difficult
>>> >>>>>>>>>> to use.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> I could pontificate on change management quite a bit more,
>>> but
>>> >> my
>>> >>>>>>>>>> opinion
>>> >>>>>>>>>>>>> in summary would basically be:  use Git the way it was meant
>>> >> to be
>>> >>>>>>>>>> used,
>>> >>>>>>>>>>>>> and things will be better.  Just my two cents.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Sam
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Sam, I think we are in agreement (at least with folks who
>>> >> responded
>>> >>>>>> to
>>> >>>>>>>>>> this thread).
>>> >>>>>>>>>>>> Or maybe I am not reading your mail right and you don't agree
>>> >> with
>>> >>>>>> Leo ?
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> My own take and reason for calling for a change we are
>>> currently
>>> >>>>>> doing
>>> >>>>>>>>>> things is mostly due to the way we release.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> I would like to see a stable master (and I think we are in
>>> >> agreement
>>> >>>>>>>>>> with that).
>>> >>>>>>>>>>>> That means that development should not happen on master and
>>> that
>>> >>>>>> every
>>> >>>>>>>>>> commit that lands on master should be shippable.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> I personally have no issues with cherry-picking. So I would be
>>> >> fine
>>> >>>>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
>>> >>>>>>>>>>>> The end result is that the next commit on master would still
>>> >> mean
>>> >>>>>>>>>> master is shippable/releasable.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> If we agree with this basic concept. The question becomes how
>>> >> do we
>>> >>>>>> get
>>> >>>>>>>>>> there, considering that master is now full of dev work and
>>> >> potential
>>> >>>>>> bug.
>>> >>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
>>> >> previous
>>> >>>>>>>>>> release branches.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our
>>> >> way
>>> >>>>>> back,
>>> >>>>>>>>>> merging the new features that are already in master into the new
>>> >>>>>> master
>>> >>>>>>>>>> (based on 4.4).
>>> >>>>>>>>>>>> This could be quite complicated but we need to do it (or
>>> >> something
>>> >>>>>> like
>>> >>>>>>>>>> it).
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> To move forward, we should make a proposal to the list and
>>> call
>>> >> for
>>> >>>>>> a
>>> >>>>>>>>>> vote.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Any takers to start a wiki page proposing a new git process
>>> and
>>> >> how
>>> >>>>>> we
>>> >>>>>>>>>> could move to it (transition path) ?
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> -Sebastien
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>>> >>>>>>>>>> LSimons@schubergphilis.com>
>>> >>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Hey folks,
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
>>> >> implement
>>> >>>>>> this?
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
>>> >>>>>>>>>> committer so
>>> >>>>>>>>>>>>>> its not that practical for me to volunteer!
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> which might be easier to read.
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Similarly, the git-flow scripts that help out with
>>> >> implementing
>>> >>>>>> this
>>> >>>>>>>>>> stuff
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> https://github.com/nvie/gitflow
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> they also describe the relationship between gitflow and
>>> >> dealing
>>> >>>>>> with
>>> >>>>>>>>>>>>>> multiple remotes
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
>>> >> support
>>> >>>>>> for
>>> >>>>>>>>>>>>>> git-flow
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> http://www.sourcetreeapp.com/
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Because cloudstack currently is full of rebasing and
>>> >> squashing and
>>> >>>>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
>>> >>>>>> visualization
>>> >>>>>>>>>> tool
>>> >>>>>>>>>>>>>> (like this or gitk or ...) right now, but it would be
>>> *great*
>>> >> to
>>> >>>>>> have
>>> >>>>>>>>>> going
>>> >>>>>>>>>>>>>> forward.
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> cheers,
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Leo
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
>>> >> runseb@gmail.com
>>> >>>>>>>
>>> >>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> I would like to re-start this discussion.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Thinking about our release procedure, we clearly need more
>>> >> tests
>>> >>>>>> and
>>> >>>>>>>>>> a
>>> >>>>>>>>>>>>>> CI. However it looks like this is going to take some time.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
>>> >>>>>> agreeing
>>> >>>>>>>>>> to
>>> >>>>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just
>>> >> need to
>>> >>>>>>>>>> agree on
>>> >>>>>>>>>>>>>> the git workflow.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Right now Master is really a development branch, we should
>>> >> make
>>> >>>>>> it a
>>> >>>>>>>>>>>>>> stable branch for production with very few commits.
>>> >>>>>>>>>>>>>>> This does not mean that we would release less, in contrary
>>> >> this
>>> >>>>>> would
>>> >>>>>>>>>>>>>> ensure that a commit to master means it's a production
>>> >> release.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back
>>> >> to
>>> >>>>>>>>>> Rajani's
>>> >>>>>>>>>>>>>> point) everything is based on merges.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> I am of the opinion that git flow provides a nice process.
>>> It
>>> >>>>>>>>>> basically
>>> >>>>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
>>> >>>>>> releases
>>> >>>>>>>>>>>>>> branches are branched off of that and merged into master and
>>> >> back
>>> >>>>>> into
>>> >>>>>>>>>>>>>> develop….etc
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Please read [1] it's a good read.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> And let's discuss,
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> [1]
>>> http://nvie.com/posts/a-successful-git-branching-model/
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> -Sebastien
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>>> >>>>>>>>>> Rajani.Karuturi@citrix.com>
>>> >>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> There is also the problem of cherry-picking.
>>> >>>>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches
>>> >> for
>>> >>>>>> each
>>> >>>>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches.
>>> >> which
>>> >>>>>> means
>>> >>>>>>>>>>>>>> distinct commits for each branch and I don’t easily know
>>> >> which all
>>> >>>>>>>>>> branches
>>> >>>>>>>>>>>>>> my commit exists unless I do grep.
>>> >>>>>>>>>>>>>>>> if we follow merging strategy properly, apart from the
>>> first
>>> >>>>>> merge
>>> >>>>>>>>>> of
>>> >>>>>>>>>>>>>> the branch, everything else on top of it should be a
>>> painless
>>> >>>>>> merge.
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> ~Rajani
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
>>> >>>>>> wrote:
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> I think many of the bullet points are what we are
>>> currently
>>> >>>>>> doing
>>> >>>>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to
>>> >> stay
>>> >>>>>> in
>>> >>>>>>>>>> sync
>>> >>>>>>>>>>>>>> with
>>> >>>>>>>>>>>>>>>>> master, no back-merging). I also think that much of what
>>> >> we do
>>> >>>>>> now
>>> >>>>>>>>>> is
>>> >>>>>>>>>>>>>> done
>>> >>>>>>>>>>>>>>>>> the way it is simply because there *are* vast changes
>>> >> between
>>> >>>>>>>>>> versions.
>>> >>>>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the
>>> >> time.
>>> >>>>>> If
>>> >>>>>>>>>> its
>>> >>>>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine,
>>> but
>>> >> some
>>> >>>>>>>>>> quick
>>> >>>>>>>>>>>>>> tests
>>> >>>>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with
>>> >> having
>>> >>>>>> single
>>> >>>>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits
>>> >> where
>>> >>>>>> each
>>> >>>>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to
>>> remember
>>> >>>>>> why we
>>> >>>>>>>>>> went
>>> >>>>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
>>> >>>>>> somewhere, but
>>> >>>>>>>>>>>>>> one of
>>> >>>>>>>>>>>>>>>>> the nice things it provides is the ability for the
>>> release
>>> >>>>>> manager
>>> >>>>>>>>>> to
>>> >>>>>>>>>>>>>>>>> control what changes are made during code freeze while
>>> >> giving
>>> >>>>>>>>>> people a
>>> >>>>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not
>>> always
>>> >>>>>>>>>> followed).
>>> >>>>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have
>>> >> their
>>> >>>>>> own
>>> >>>>>>>>>>>>>> repo and
>>> >>>>>>>>>>>>>>>>> issue pull requests for bugfixes?
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>> >>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>> >>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
>>> >>>>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> ~Rajani
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>> >>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>> >>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a
>>> empty
>>> >>>>>>>>>>>>>> merge(merge -s
>>> >>>>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
>>> >>>>>> bring in
>>> >>>>>>>>>> any
>>> >>>>>>>>>>>>>>>>>> changes.
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a
>>> major
>>> >>>>>>>>>> rewrite, we
>>> >>>>>>>>>>>>>>>>>> could stop merging to that branch and above and make the
>>> >> fix
>>> >>>>>>>>>> manually.
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> ~Rajani
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>> >>>>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a
>>> >> particular fix
>>> >>>>>>>>>> for an
>>> >>>>>>>>>>>>>> old
>>> >>>>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does
>>> >> happen.
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to
>>> branch
>>> >> x"
>>> >>>>>> in
>>> >>>>>>>>>> SVN
>>> >>>>>>>>>>>>>> and
>>> >>>>>>>>>>>>>>>>>> then
>>> >>>>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
>>> >>>>>> branch(es).
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>> >>>>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
>>> >>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
>>> >> versions, or
>>> >>>>>>>>>> has to
>>> >>>>>>>>>>>>>> be
>>> >>>>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
>>> >> changed?
>>> >>>>>>>>>> Don't
>>> >>>>>>>>>>>>>> the
>>> >>>>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after
>>> >> that?
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> --
>>> >>>>>>>>>>>>>>>>>>>>> Stephen Turner
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>> >>>>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
>>> >> mike.tutkowski@solidfire.com]
>>> >>>>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>>> >>>>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>>> >>>>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
>>> >>>>>> consider.
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be
>>> error
>>> >>>>>> prone
>>> >>>>>>>>>> in
>>> >>>>>>>>>>>>>> that
>>> >>>>>>>>>>>>>>>>>> it's
>>> >>>>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
>>> >> applicable
>>> >>>>>>>>>>>>>> branches
>>> >>>>>>>>>>>>>>>>>> and
>>> >>>>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks
>>> are
>>> >>>>>>>>>> related.
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to
>>> >> see
>>> >>>>>> if you
>>> >>>>>>>>>>>>>>>>>> checked a
>>> >>>>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In
>>> >> such a
>>> >>>>>>>>>>>>>> situation,
>>> >>>>>>>>>>>>>>>>>> you
>>> >>>>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
>>> >> check-in
>>> >>>>>>>>>> was no
>>> >>>>>>>>>>>>>>>>>> longer
>>> >>>>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to
>>> >> mark
>>> >>>>>> it as
>>> >>>>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure
>>> >> about
>>> >>>>>> Git).
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>> >>>>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> Hi all,
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the
>>> >> *forward
>>> >>>>>>>>>> branches
>>> >>>>>>>>>>>>>> and
>>> >>>>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all
>>> >> releases the
>>> >>>>>>>>>> commit
>>> >>>>>>>>>>>>>> has
>>> >>>>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also,
>>> as a
>>> >>>>>>>>>>>>>> contributor, I
>>> >>>>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
>>> >>>>>> cleanly
>>> >>>>>>>>>>>>>> apply on
>>> >>>>>>>>>>>>>>>>>>>>>> different branches.
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is
>>> what I
>>> >>>>>>>>>> propose.
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major
>>> release(ex:
>>> >>>>>> 4.3.x,
>>> >>>>>>>>>>>>>> 4.4.x,
>>> >>>>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>>> >>>>>>>>>> accordingly
>>> >>>>>>>>>>>>>> on
>>> >>>>>>>>>>>>>>>>>>>>>> the respective branches.
>>> >>>>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed.
>>> >> Many
>>> >>>>>>>>>> branches
>>> >>>>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>> >>>>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when
>>> we
>>> >>>>>>>>>> cherry-pick,
>>> >>>>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
>>> >>>>>> change or
>>> >>>>>>>>>>>>>> fix and
>>> >>>>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>> >>>>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
>>> >> release
>>> >>>>>>>>>> branches
>>> >>>>>>>>>>>>>> to
>>> >>>>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They
>>> should
>>> >> be
>>> >>>>>>>>>>>>>> merged(either
>>> >>>>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
>>> >>>>>> trackable
>>> >>>>>>>>>>>>>> with
>>> >>>>>>>>>>>>>>>>>>>>>> git branch --contains
>>> >>>>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
>>> >> release
>>> >>>>>>>>>> uptill
>>> >>>>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches
>>> master.
>>> >>>>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>> >>>>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>> >>>>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next
>>> time
>>> >> a
>>> >>>>>> new
>>> >>>>>>>>>> commit
>>> >>>>>>>>>>>>>>>>>>>>> is
>>> >>>>>>>>>>>>>>>>>>>>>> done this will also get merged.
>>> >>>>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
>>> >> master
>>> >>>>>> to
>>> >>>>>>>>>>>>>> feature
>>> >>>>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
>>> >>>>>> proactively
>>> >>>>>>>>>>>>>> take
>>> >>>>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
>>> >> master
>>> >>>>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
>>> >> master on
>>> >>>>>>>>>> code
>>> >>>>>>>>>>>>>>>>>>>>>> complete through a merge.
>>> >>>>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
>>> >> release
>>> >>>>>>>>>> branches
>>> >>>>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any
>>> minor
>>> >>>>>> release)
>>> >>>>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
>>> >> information
>>> >>>>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>;
>>> reviewed
>>> >> by
>>> >>>>>>>>>>>>>>>>>> <committer>
>>> >>>>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>>> >>>>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
>>> >> freeze),
>>> >>>>>>>>>> any bug
>>> >>>>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
>>> >>>>>> release(4.4)
>>> >>>>>>>>>> only
>>> >>>>>>>>>>>>>> on
>>> >>>>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
>>> >> branch.
>>> >>>>>>>>>> This
>>> >>>>>>>>>>>>>> can be
>>> >>>>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be
>>> using
>>> >>>>>> jira
>>> >>>>>>>>>> vote?)
>>> >>>>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another
>>> >> branch
>>> >>>>>>>>>>>>>>>>>> maintenance.
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> Ref:
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>
>>> >>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>> >>>>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> ~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
>>> >>> *™*
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> --
>>> >>>>>>>>>>>>>>>>>>>> *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
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> --
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> *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.
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> --
>>> >>>>>> 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>*™*
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> 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>*™*
>>>
>>>
>
>
>
> --
> Daan



-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

That seems to handle my concern :-)

Erik
25. juli 2014 13:16 skrev "Rajani Karuturi" <Ra...@citrix.com>
følgende:

> branches will be deleted after the release or hotfix if you use the
> git-flow commands.
>
> This would be the flow for a hotfix:
> 1. branch off from the release tag on master. in this case it would be
> release/4.4.0
> 2. commit the fixes in hotfix/4.4.1
> 3. do the release
> 4. merge to develop
> 5. merge to master and update tags
> 6. delete hotfix branch
>
> But, I agree that there can be a problem when we wish to do 4.4.2 if we
> delete the hotfix branch
>
> may be we should use git-flow support instead of hotfix which doesn’t
> delete the branch
> http://stackoverflow.com/a/16866118/201514
>
> ~Rajani
>
>
>
> On 25-Jul-2014, at 12:31 pm, Daan Hoogland <da...@gmail.com>
> wrote:
>
> > Rightful question Erik,
> >
> > Rajani mentioned that release branches will be deleted. This will only
> > happen once the release is no longer supported. Any hotfix branch will
> > still have to merged on that (and master possibly) until we stop
> > supporting that branch.
> >
> > On the other hand you can branch from any commit.
> >
> > btw 4.4.1 is a bad example of you as we will still maintain that
> > without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.
> >
> > On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber <te...@gmail.com> wrote:
> >> This is out of my git league, but how do you handle minor versions that
> way?
> >>
> >> Assuming 4.8.0 is the latest stable release and HEAD on master.
> >>
> >> Then you want to release 4.4.1.
> >>
> >> First of all can you develop bugfixes for 4.4 along the way, when both
> >> develop and master HEAD might be hugely different?
> >>
> >> Second, can you commit  behind HEAD? You don't want the 4.4.1 release
> >> instead of 4.8.0 to be HEAD
> >>
> >> Someone might have good solutions to this, but if not I would propose to
> >> keep the release branches for future bugfixes.
> >>
> >> Erik
> >> 25. juli 2014 06:02 skrev "Rajani Karuturi" <Rajani.Karuturi@citrix.com
> >
> >> følgende:
> >>
> >>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <
> mike.tutkowski@solidfire.com>
> >>> wrote:
> >>>
> >>>> I believe I agree with these steps.
> >>>>
> >>>> A couple questions:
> >>>>
> >>>> Is 'master' simply always going to be equal to what's the most recent
> >>>> version of the code that's in production?
> >>>
> >>> I think so. master will always be at the latest release and all the
> >>> previous releases properly tagged. The release branches would be
> deleted
> >>> once release is done.
> >>>
> >>>>
> >>>> Also, would 'develop' be for 4.6 code then and 4.5 code would go
> directly
> >>>> into RELEASE-4.5?
> >>>>
> >>>
> >>> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
> >>> should be done on the 4.5 branch.
> >>>
> >>>
> >>>
> >>> ~Rajani
> >>>
> >>>
> >>>>
> >>>> On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
> >>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>
> >>>>>
> >>>>> Hi Daan,
> >>>>> here is what i propose:
> >>>>>
> >>>>> 1. rename 'master' to 'develop’
> >>>>> 2. branch a new 'master' from '4.4’
> >>>>> 3. branch 'RELEASE-4.5' from the develop
> >>>>> 4. merge 'RELEASE-4.5' to master once the release voting is done.
> >>>>>
> >>>>> RELEASE-4.6 branch should be off develop as all the feature branches
> >>> would
> >>>>> be merged there before freeze for 4.6 and would be merged to master
> when
> >>>>> the release is voted.
> >>>>>
> >>>>> The other question I have is in the step:4. how are we going to
> manage
> >>>>> fixes to 4.5 post branch cut?  ( assuming no features as the freeze
> is
> >>> done)
> >>>>>
> >>>>> ~Rajani
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Mike, Rajani,
> >>>>>>
> >>>>>> Sebastien's point was that the current 4.4 is the closest we have
> to a
> >>>>>> releasable branch. I don't mind enting on master but it will require
> >>>>>> more fixing. In general all of this will require some RM work of all
> >>>>>> committers. Please ammend my little proposal if you will.
> >>>>>>
> >>>>>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
> >>>>>> <Ra...@citrix.com> wrote:
> >>>>>>> I agree with mike. I think we should start 4.5 from where master is
> >>> now
> >>>>>>> Also create a develop branch from master and continue future work
> for
> >>>>> 4.6 there.
> >>>>>>>
> >>>>>>> I am not clear on how the release branches are going to be
> maintained.
> >>>>>>> Are we saying we would create 4.5-RELEASE branch which is
> essentially
> >>>>> same as our current -FORWARD branch and continue cherry-picking?
> >>>>>>>
> >>>>>>> I would prefer merges to cherry-picks.
> >>>>>>> Also, I think we should allow committers to commit to the RELEASE
> >>>>> branch after discussing about it on dev@ and have RM closely monitor
> >>> them.
> >>>>>>> Any commit intended for 4.5 RELEASE should be checked in after
> >>>>> discussion in the 4.5 Release branch and then merged to develop
> branch.
> >>>>>>>
> >>>>>>>
> >>>>>>> ~Rajani
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
> >>>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>>>
> >>>>>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
> >>> left
> >>>>> off
> >>>>>>>> and then merge features from develop into 4.5.
> >>>>>>>>
> >>>>>>>> Why don't we instead start 4.5 where master is now with the
> >>> assumption
> >>>>> that
> >>>>>>>> since we are past Feature Freeze for 4.5 that master is stable
> >>> enough?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
> >>>>> daan.hoogland@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> so to start formulate a proposal:
> >>>>>>>>>
> >>>>>>>>> all work shall be done in a new branch (it is advisable to prefix
> >>> your
> >>>>>>>>> branches with your id)
> >>>>>>>>> when working, features will be cherry-picked/merged into the
> release
> >>>>>>>>> branch they are for and next into master.
> >>>>>>>>> hotfixes will be done in <branchname>-hotfixes
> >>>>>>>>>
> >>>>>>>>> as transition we will
> >>>>>>>>>
> >>>>>>>>> rename 'master' to 'develop'
> >>>>>>>>> branch a new 'master' from '4.4'
> >>>>>>>>> branch '4.5' from the new 'master'
> >>>>>>>>> merge any features from the new 'develop' to '4.5' and 'master'
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <
> >>> runseb@gmail.com
> >>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <
> runseb@gmail.com
> >>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <
> >>> nate.gordon@appcore.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Let me ask the question, why have master be develop and a
> release
> >>>>>>>>> branch be
> >>>>>>>>>>>> "master"? If we are going to follow gitflow, why not just
> stick
> >>>>> with
> >>>>>>>>> the
> >>>>>>>>>>>> norm? If master is the development branch, it might not be
> >>> stable.
> >>>>> I
> >>>>>>>>> think
> >>>>>>>>>>>> the goal here is that we have an obvious stable branch. Anyone
> >>>>> could
> >>>>>>>>> come
> >>>>>>>>>>>> check out master and have the latest useable.
> >>>>>>>>>>>
> >>>>>>>>>>> I am in favor of following the norm, so ideally master should
> be
> >>> our
> >>>>>>>>> stable branch (agreed).
> >>>>>>>>>>>
> >>>>>>>>>>> The issue is with the transition.
> >>>>>>>>>>>
> >>>>>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
> >>>>> ideally
> >>>>>>>>> we could start a stable branch of this tag and build up bug fix
> >>>>> releases
> >>>>>>>>> all the way to 4.5 from there.
> >>>>>>>>>>>
> >>>>>>>>>>> But all features for 4.5 are already in master.
> >>>>>>>>>>>
> >>>>>>>>>>> So if we create a 'develop' branch of master and stabilize
> >>> 'master'
> >>>>>>>>> then develop is now started from a stable tag (4.4.0).
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> *not* started from a stable tag, and merges will be tricky, no ?
> >>>>>>>>>>
> >>>>>>>>>>> So what's the best way to flip ? There is most likely some git
> >>> magic
> >>>>>>>>> that can we do.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The new git workflow and the transition process need to be part
> >>> of a
> >>>>>>>>> proposal that we get consensus on.
> >>>>>>>>>>>
> >>>>>>>>>>> getting there :)
> >>>>>>>>>>>
> >>>>>>>>>>> -seb
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Also, I'm struggling to understand the benefit of
> cherry-pick. If
> >>>>> you
> >>>>>>>>>>>> completely squash history, you lose a tremendous amount of
> >>> context,
> >>>>>>>>> which I
> >>>>>>>>>>>> use extensively to figure out why a bug is the way it is. Only
> >>>>> knowing
> >>>>>>>>> that
> >>>>>>>>>>>> the branch was merged at a given point in time doesn't give
> any
> >>>>>>>>> context.
> >>>>>>>>>>>> Seeing the individual commit history of the branch helps to
> >>>>> preserve
> >>>>>>>>> the
> >>>>>>>>>>>> rationale for why the code was written the way it was. In
> theory
> >>> if
> >>>>>>>>> every
> >>>>>>>>>>>> change starts out as a branch (feature, hotfix, release), then
> >>> why
> >>>>> not
> >>>>>>>>> just
> >>>>>>>>>>>> merge the branch once it is in a good and acceptable state?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I also agree with Mike that this will have to be a transition
> >>> over
> >>>>>>>>> time. It
> >>>>>>>>>>>> will take some time to clean up master to the point where it
> can
> >>> be
> >>>>>>>>>>>> considered a solid stable branch. Possibly as part of the 4.5
> >>>>> release.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
> >>>>> runseb@gmail.com
> >>>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <
> >>>>> daan.hoogland@gmail.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Sebastien,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It seems we can do what you are calling for is creating a
> >>> branch
> >>>>>>>>>>>>>> called 'release'. We can merge back into that branch from
> 4.4,
> >>>>>>>>> master,
> >>>>>>>>>>>>>> 4.3. I would like to see people that want a feature or bug
> fix
> >>>>> in a
> >>>>>>>>>>>>>> branch make a fork of that branch and when that fork is
> working
> >>>>> do a
> >>>>>>>>>>>>>> cherry-pick. The -forward concept is now used for that but
> it
> >>> is
> >>>>>>>>>>>>>> broken because more then for one piece of work there are
> >>> commits
> >>>>> on
> >>>>>>>>>>>>>> it. This caused me conflicts during the release. Especially
> >>>>> painfull
> >>>>>>>>>>>>>> as not all was intended to get into the release. We can
> create
> >>>>> this
> >>>>>>>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling
> in
> >>>>>>>>> changes.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Yes, that's what I am thinking about too, so +1
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Our master would become the -develop- in gitflow terms
> >>>>>>>>>>>>> The release branch you mention would become the -master- in
> >>>>> gitflow
> >>>>>>>>> terms
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If we start now, indeed we can create 'release' from 4.4
> release
> >>>>> tag
> >>>>>>>>>>>>> (voted and shipped).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That means that to create 4.5 we will need to merge features
> >>> back
> >>>>> into
> >>>>>>>>>>>>> 'release'. it might be messy because some of those features
> are
> >>>>>>>>> already in
> >>>>>>>>>>>>> our current master.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But all of this will keep 'release' clean (we can keep track
> of
> >>>>> bugs
> >>>>>>>>> and
> >>>>>>>>>>>>> features that are in it in CHANGES file etc..)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> There is a question of control. Do we allow all committers
> to
> >>>>> manage
> >>>>>>>>>>>>>> the release? I am for that but can imagine not everybody is.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> At first I would say that only the RM can commit to
> 'release'.
> >>> As
> >>>>> we
> >>>>>>>>> get
> >>>>>>>>>>>>> the CI in place  we could relax this and allow commits that
> pass
> >>>>> the
> >>>>>>>>> CI to
> >>>>>>>>>>>>> get into 'release', but right now I would vote for a tighter
> >>>>> control
> >>>>>>>>> of
> >>>>>>>>>>>>> 'release'.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> rule number 1 will be: you are going to do something to the
> >>>>> code, you
> >>>>>>>>>>>>>> start by creating a branch.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> right?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
> >>>>>>>>> runseb@gmail.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <
> >>>>> sam.schmit@appcore.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hey everyone,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I've been a developer for a handful of years and have had
> my
> >>>>> share
> >>>>>>>>> of
> >>>>>>>>>>>>>>>> experience with different version control systems.  I've
> used
> >>>>> (for
> >>>>>>>>>>>>> better
> >>>>>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Each of these solutions offers their own unique set of
> >>>>> features,
> >>>>>>>>>>>>> strengths
> >>>>>>>>>>>>>>>> and weaknesses.  As there are so many systems that are
> good
> >>> at
> >>>>>>>>> specific
> >>>>>>>>>>>>>>>> things, it seems best to use the features that the chosen
> >>>>> system is
> >>>>>>>>>>>>> best at.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Git is great at branching, merging and using that
> structure
> >>> to
> >>>>>>>>>>>>> maintain and
> >>>>>>>>>>>>>>>> control how changes get into the primary branches.  Git
> tools
> >>>>> even
> >>>>>>>>> make
> >>>>>>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to
> make
> >>>>>>>>> branching
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> merging that much easier.  It would seem
> counter-intuitive to
> >>>>> NOT
> >>>>>>>>> make
> >>>>>>>>>>>>> use
> >>>>>>>>>>>>>>>> of these built-in capabilities.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> In addition to that, I know that the current method of
> change
> >>>>>>>>>>>>> management is
> >>>>>>>>>>>>>>>> incredibly frustrating to work with, and works directly
> >>>>> against the
> >>>>>>>>>>>>> way a
> >>>>>>>>>>>>>>>> typical Git user would expect it to be structured.  I
> should
> >>>>> NEVER
> >>>>>>>>> have
> >>>>>>>>>>>>>>>> problem compiling and running something on master.  I
> should
> >>>>> not
> >>>>>>>>> have
> >>>>>>>>>>>>>>>> problems building anything on a release branch.  A
> >>>>> feature/bugfix
> >>>>>>>>>>>>> branch is
> >>>>>>>>>>>>>>>> where things can be, and often are, broken or unstable.
> >>> There
> >>>>> have
> >>>>>>>>>>>>> been
> >>>>>>>>>>>>>>>> many times working in Cloudstack where I've had to search
> >>> for a
> >>>>>>>>> stable
> >>>>>>>>>>>>>>>> revision on master, and that's just plain wrong.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I do realize that having this many developers working on
> so
> >>>>> many
> >>>>>>>>>>>>> features
> >>>>>>>>>>>>>>>> and bugfixes will result in a large number of branches.  I
> >>>>> don't
> >>>>>>>>>>>>> believe
> >>>>>>>>>>>>>>>> this is a good argument against using a branching method,
> >>>>> though -
> >>>>>>>>> I
> >>>>>>>>>>>>>>>> believe that the current system is even more confusing and
> >>>>>>>>> difficult
> >>>>>>>>>>>>> to use.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I could pontificate on change management quite a bit more,
> >>> but
> >>>>> my
> >>>>>>>>>>>>> opinion
> >>>>>>>>>>>>>>>> in summary would basically be:  use Git the way it was
> meant
> >>>>> to be
> >>>>>>>>>>>>> used,
> >>>>>>>>>>>>>>>> and things will be better.  Just my two cents.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Sam
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Sam, I think we are in agreement (at least with folks who
> >>>>> responded
> >>>>>>>>> to
> >>>>>>>>>>>>> this thread).
> >>>>>>>>>>>>>>> Or maybe I am not reading your mail right and you don't
> agree
> >>>>> with
> >>>>>>>>> Leo ?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> My own take and reason for calling for a change we are
> >>> currently
> >>>>>>>>> doing
> >>>>>>>>>>>>> things is mostly due to the way we release.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I would like to see a stable master (and I think we are in
> >>>>> agreement
> >>>>>>>>>>>>> with that).
> >>>>>>>>>>>>>>> That means that development should not happen on master and
> >>> that
> >>>>>>>>> every
> >>>>>>>>>>>>> commit that lands on master should be shippable.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I personally have no issues with cherry-picking. So I
> would be
> >>>>> fine
> >>>>>>>>>>>>> cherry picking from a hot-fix branch into master, to fix a
> bug.
> >>>>>>>>>>>>>>> The end result is that the next commit on master would
> still
> >>>>> mean
> >>>>>>>>>>>>> master is shippable/releasable.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If we agree with this basic concept. The question becomes
> how
> >>>>> do we
> >>>>>>>>> get
> >>>>>>>>>>>>> there, considering that master is now full of dev work and
> >>>>> potential
> >>>>>>>>> bug.
> >>>>>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
> >>>>> previous
> >>>>>>>>>>>>> release branches.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work
> our
> >>>>> way
> >>>>>>>>> back,
> >>>>>>>>>>>>> merging the new features that are already in master into the
> new
> >>>>>>>>> master
> >>>>>>>>>>>>> (based on 4.4).
> >>>>>>>>>>>>>>> This could be quite complicated but we need to do it (or
> >>>>> something
> >>>>>>>>> like
> >>>>>>>>>>>>> it).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> To move forward, we should make a proposal to the list and
> >>> call
> >>>>> for
> >>>>>>>>> a
> >>>>>>>>>>>>> vote.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Any takers to start a wiki page proposing a new git process
> >>> and
> >>>>> how
> >>>>>>>>> we
> >>>>>>>>>>>>> could move to it (transition path) ?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Sebastien
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
> >>>>>>>>>>>>> LSimons@schubergphilis.com>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hey folks,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
> >>>>> implement
> >>>>>>>>> this?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m
> not a
> >>>>>>>>>>>>> committer so
> >>>>>>>>>>>>>>>>> its not that practical for me to volunteer!
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> https://www.atlassian.com/git/workflows#!workflow-gitflow
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> which might be easier to read.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Similarly, the git-flow scripts that help out with
> >>>>> implementing
> >>>>>>>>> this
> >>>>>>>>>>>>> stuff
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> https://github.com/nvie/gitflow
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> they also describe the relationship between gitflow and
> >>>>> dealing
> >>>>>>>>> with
> >>>>>>>>>>>>>>>>> multiple remotes
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
> >>>>> support
> >>>>>>>>> for
> >>>>>>>>>>>>>>>>> git-flow
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> http://www.sourcetreeapp.com/
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Because cloudstack currently is full of rebasing and
> >>>>> squashing and
> >>>>>>>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
> >>>>>>>>> visualization
> >>>>>>>>>>>>> tool
> >>>>>>>>>>>>>>>>> (like this or gitk or ...) right now, but it would be
> >>> *great*
> >>>>> to
> >>>>>>>>> have
> >>>>>>>>>>>>> going
> >>>>>>>>>>>>>>>>> forward.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> cheers,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Leo
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
> >>>>> runseb@gmail.com
> >>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I would like to re-start this discussion.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Rajani made some good points and someone mentioned
> Gitflow:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thinking about our release procedure, we clearly need
> more
> >>>>> tests
> >>>>>>>>> and
> >>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>> CI. However it looks like this is going to take some
> time.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> In the meantime I think there is nothing preventing us
> from
> >>>>>>>>> agreeing
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> 'git practices', we don't need tests or new infra, we
> just
> >>>>> need to
> >>>>>>>>>>>>> agree on
> >>>>>>>>>>>>>>>>> the git workflow.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Right now Master is really a development branch, we
> should
> >>>>> make
> >>>>>>>>> it a
> >>>>>>>>>>>>>>>>> stable branch for production with very few commits.
> >>>>>>>>>>>>>>>>>> This does not mean that we would release less, in
> contrary
> >>>>> this
> >>>>>>>>> would
> >>>>>>>>>>>>>>>>> ensure that a commit to master means it's a production
> >>>>> release.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets
> back
> >>>>> to
> >>>>>>>>>>>>> Rajani's
> >>>>>>>>>>>>>>>>> point) everything is based on merges.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I am of the opinion that git flow provides a nice
> process.
> >>> It
> >>>>>>>>>>>>> basically
> >>>>>>>>>>>>>>>>> freezes master. Development happens in a 'develop'
> branch,
> >>>>>>>>> releases
> >>>>>>>>>>>>>>>>> branches are branched off of that and merged into master
> and
> >>>>> back
> >>>>>>>>> into
> >>>>>>>>>>>>>>>>> develop….etc
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Please read [1] it's a good read.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> And let's discuss,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> [1]
> >>> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -Sebastien
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
> >>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> There is also the problem of cherry-picking.
> >>>>>>>>>>>>>>>>>>> As a contributor, I always endup creating multiple
> patches
> >>>>> for
> >>>>>>>>> each
> >>>>>>>>>>>>>>>>> branch as they don’t cleanly apply on the upward
> branches.
> >>>>> which
> >>>>>>>>> means
> >>>>>>>>>>>>>>>>> distinct commits for each branch and I don’t easily know
> >>>>> which all
> >>>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>>> my commit exists unless I do grep.
> >>>>>>>>>>>>>>>>>>> if we follow merging strategy properly, apart from the
> >>> first
> >>>>>>>>> merge
> >>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>> the branch, everything else on top of it should be a
> >>> painless
> >>>>>>>>> merge.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <
> shadowsor@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I think many of the bullet points are what we are
> >>> currently
> >>>>>>>>> doing
> >>>>>>>>>>>>>>>>>>>> (guidelines for commit comments, feature branches
> need to
> >>>>> stay
> >>>>>>>>> in
> >>>>>>>>>>>>> sync
> >>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>> master, no back-merging). I also think that much of
> what
> >>>>> we do
> >>>>>>>>> now
> >>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>> done
> >>>>>>>>>>>>>>>>>>>> the way it is simply because there *are* vast changes
> >>>>> between
> >>>>>>>>>>>>> versions.
> >>>>>>>>>>>>>>>>>>>> Classes are getting shuffled around and changed all
> the
> >>>>> time.
> >>>>>>>>> If
> >>>>>>>>>>>>> its
> >>>>>>>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine,
> >>> but
> >>>>> some
> >>>>>>>>>>>>> quick
> >>>>>>>>>>>>>>>>> tests
> >>>>>>>>>>>>>>>>>>>> seem to indicate that this will be messy getting
> started.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with
> >>>>> having
> >>>>>>>>> single
> >>>>>>>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the
> commits
> >>>>> where
> >>>>>>>>> each
> >>>>>>>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to
> >>> remember
> >>>>>>>>> why we
> >>>>>>>>>>>>> went
> >>>>>>>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
> >>>>>>>>> somewhere, but
> >>>>>>>>>>>>>>>>> one of
> >>>>>>>>>>>>>>>>>>>> the nice things it provides is the ability for the
> >>> release
> >>>>>>>>> manager
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> control what changes are made during code freeze while
> >>>>> giving
> >>>>>>>>>>>>> people a
> >>>>>>>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not
> >>> always
> >>>>>>>>>>>>> followed).
> >>>>>>>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to
> have
> >>>>> their
> >>>>>>>>> own
> >>>>>>>>>>>>>>>>> repo and
> >>>>>>>>>>>>>>>>>>>> issue pull requests for bugfixes?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> >>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
> >>>>>>>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a
> process??
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> >>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a
> >>> empty
> >>>>>>>>>>>>>>>>> merge(merge -s
> >>>>>>>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will
> not
> >>>>>>>>> bring in
> >>>>>>>>>>>>> any
> >>>>>>>>>>>>>>>>>>>>> changes.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a
> >>> major
> >>>>>>>>>>>>> rewrite, we
> >>>>>>>>>>>>>>>>>>>>> could stop merging to that branch and above and make
> the
> >>>>> fix
> >>>>>>>>>>>>> manually.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>>>>>>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a
> >>>>> particular fix
> >>>>>>>>>>>>> for an
> >>>>>>>>>>>>>>>>> old
> >>>>>>>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does
> >>>>> happen.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to
> >>> branch
> >>>>> x"
> >>>>>>>>> in
> >>>>>>>>>>>>> SVN
> >>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
> >>>>>>>>> branch(es).
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>>>>>>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
> >>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
> >>>>> versions, or
> >>>>>>>>>>>>> has to
> >>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
> >>>>> changed?
> >>>>>>>>>>>>> Don't
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking
> after
> >>>>> that?
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>> Stephen Turner
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
> >>>>> mike.tutkowski@solidfire.com]
> >>>>>>>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
> >>>>>>>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
> >>>>>>>>> consider.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be
> >>> error
> >>>>>>>>> prone
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
> >>>>> applicable
> >>>>>>>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry
> picks
> >>> are
> >>>>>>>>>>>>> related.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check
> to
> >>>>> see
> >>>>>>>>> if you
> >>>>>>>>>>>>>>>>>>>>> checked a
> >>>>>>>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases.
> In
> >>>>> such a
> >>>>>>>>>>>>>>>>> situation,
> >>>>>>>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
> >>>>> check-in
> >>>>>>>>>>>>> was no
> >>>>>>>>>>>>>>>>>>>>> longer
> >>>>>>>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed
> to
> >>>>> mark
> >>>>>>>>> it as
> >>>>>>>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not
> sure
> >>>>> about
> >>>>>>>>> Git).
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi
> <
> >>>>>>>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the
> >>>>> *forward
> >>>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all
> >>>>> releases the
> >>>>>>>>>>>>> commit
> >>>>>>>>>>>>>>>>> has
> >>>>>>>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also,
> >>> as a
> >>>>>>>>>>>>>>>>> contributor, I
> >>>>>>>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it
> doesn’t
> >>>>>>>>> cleanly
> >>>>>>>>>>>>>>>>> apply on
> >>>>>>>>>>>>>>>>>>>>>>>>> different branches.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is
> >>> what I
> >>>>>>>>>>>>> propose.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major
> >>> release(ex:
> >>>>>>>>> 4.3.x,
> >>>>>>>>>>>>>>>>> 4.4.x,
> >>>>>>>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be
> tagged
> >>>>>>>>>>>>> accordingly
> >>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>>>> the respective branches.
> >>>>>>>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be
> followed.
> >>>>> Many
> >>>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git,
> when
> >>> we
> >>>>>>>>>>>>> cherry-pick,
> >>>>>>>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the
> same
> >>>>>>>>> change or
> >>>>>>>>>>>>>>>>> fix and
> >>>>>>>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick
> -x
> >>>>>>>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
> >>>>> release
> >>>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They
> >>> should
> >>>>> be
> >>>>>>>>>>>>>>>>> merged(either
> >>>>>>>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and
> easily
> >>>>>>>>> trackable
> >>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>>>> git branch --contains
> >>>>>>>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
> >>>>> release
> >>>>>>>>>>>>> uptill
> >>>>>>>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches
> >>> master.
> >>>>>>>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> >>>>>>>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next
> >>> time
> >>>>> a
> >>>>>>>>> new
> >>>>>>>>>>>>> commit
> >>>>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>> done this will also get merged.
> >>>>>>>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
> >>>>> master
> >>>>>>>>> to
> >>>>>>>>>>>>>>>>> feature
> >>>>>>>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners
> should
> >>>>>>>>> proactively
> >>>>>>>>>>>>>>>>> take
> >>>>>>>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
> >>>>> master
> >>>>>>>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
> >>>>> master on
> >>>>>>>>>>>>> code
> >>>>>>>>>>>>>>>>>>>>>>>>> complete through a merge.
> >>>>>>>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
> >>>>> release
> >>>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any
> >>> minor
> >>>>>>>>> release)
> >>>>>>>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
> >>>>> information
> >>>>>>>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>;
> >>> reviewed
> >>>>> by
> >>>>>>>>>>>>>>>>>>>>> <committer>
> >>>>>>>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
> >>>>>>>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
> >>>>> freeze),
> >>>>>>>>>>>>> any bug
> >>>>>>>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
> >>>>>>>>> release(4.4)
> >>>>>>>>>>>>> only
> >>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
> >>>>> branch.
> >>>>>>>>>>>>> This
> >>>>>>>>>>>>>>>>> can be
> >>>>>>>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be
> >>> using
> >>>>>>>>> jira
> >>>>>>>>>>>>> vote?)
> >>>>>>>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and
> another
> >>>>> branch
> >>>>>>>>>>>>>>>>>>>>> maintenance.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Ref:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> ~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
> >>>>>> *™*
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>> *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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> *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.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> 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>*™*
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> 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>*™*
> >>>
> >>>
> >
> >
> >
> > --
> > Daan
>
>

Re: [DISCUSS][PROPOSAL] git workflow

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

On Fri, Jul 25, 2014 at 1:16 PM, Rajani Karuturi
<Ra...@citrix.com> wrote:
> may be we should use git-flow support instead of hotfix which doesn’t delete the branch


Good call Rajani

-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

branches will be deleted after the release or hotfix if you use the git-flow commands.

This would be the flow for a hotfix:
1. branch off from the release tag on master. in this case it would be release/4.4.0 
2. commit the fixes in hotfix/4.4.1
3. do the release
4. merge to develop
5. merge to master and update tags
6. delete hotfix branch

But, I agree that there can be a problem when we wish to do 4.4.2 if we delete the hotfix branch

may be we should use git-flow support instead of hotfix which doesn’t delete the branch
http://stackoverflow.com/a/16866118/201514

~Rajani



On 25-Jul-2014, at 12:31 pm, Daan Hoogland <da...@gmail.com> wrote:

> Rightful question Erik,
> 
> Rajani mentioned that release branches will be deleted. This will only
> happen once the release is no longer supported. Any hotfix branch will
> still have to merged on that (and master possibly) until we stop
> supporting that branch.
> 
> On the other hand you can branch from any commit.
> 
> btw 4.4.1 is a bad example of you as we will still maintain that
> without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.
> 
> On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber <te...@gmail.com> wrote:
>> This is out of my git league, but how do you handle minor versions that way?
>> 
>> Assuming 4.8.0 is the latest stable release and HEAD on master.
>> 
>> Then you want to release 4.4.1.
>> 
>> First of all can you develop bugfixes for 4.4 along the way, when both
>> develop and master HEAD might be hugely different?
>> 
>> Second, can you commit  behind HEAD? You don't want the 4.4.1 release
>> instead of 4.8.0 to be HEAD
>> 
>> Someone might have good solutions to this, but if not I would propose to
>> keep the release branches for future bugfixes.
>> 
>> Erik
>> 25. juli 2014 06:02 skrev "Rajani Karuturi" <Ra...@citrix.com>
>> følgende:
>> 
>>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <mi...@solidfire.com>
>>> wrote:
>>> 
>>>> I believe I agree with these steps.
>>>> 
>>>> A couple questions:
>>>> 
>>>> Is 'master' simply always going to be equal to what's the most recent
>>>> version of the code that's in production?
>>> 
>>> I think so. master will always be at the latest release and all the
>>> previous releases properly tagged. The release branches would be deleted
>>> once release is done.
>>> 
>>>> 
>>>> Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
>>>> into RELEASE-4.5?
>>>> 
>>> 
>>> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
>>> should be done on the 4.5 branch.
>>> 
>>> 
>>> 
>>> ~Rajani
>>> 
>>> 
>>>> 
>>>> On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
>>>> Rajani.Karuturi@citrix.com> wrote:
>>>> 
>>>>> 
>>>>> Hi Daan,
>>>>> here is what i propose:
>>>>> 
>>>>> 1. rename 'master' to 'develop’
>>>>> 2. branch a new 'master' from '4.4’
>>>>> 3. branch 'RELEASE-4.5' from the develop
>>>>> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>>>>> 
>>>>> RELEASE-4.6 branch should be off develop as all the feature branches
>>> would
>>>>> be merged there before freeze for 4.6 and would be merged to master when
>>>>> the release is voted.
>>>>> 
>>>>> The other question I have is in the step:4. how are we going to manage
>>>>> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is
>>> done)
>>>>> 
>>>>> ~Rajani
>>>>> 
>>>>> 
>>>>> 
>>>>> On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> Mike, Rajani,
>>>>>> 
>>>>>> Sebastien's point was that the current 4.4 is the closest we have to a
>>>>>> releasable branch. I don't mind enting on master but it will require
>>>>>> more fixing. In general all of this will require some RM work of all
>>>>>> committers. Please ammend my little proposal if you will.
>>>>>> 
>>>>>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
>>>>>> <Ra...@citrix.com> wrote:
>>>>>>> I agree with mike. I think we should start 4.5 from where master is
>>> now
>>>>>>> Also create a develop branch from master and continue future work for
>>>>> 4.6 there.
>>>>>>> 
>>>>>>> I am not clear on how the release branches are going to be maintained.
>>>>>>> Are we saying we would create 4.5-RELEASE branch which is essentially
>>>>> same as our current -FORWARD branch and continue cherry-picking?
>>>>>>> 
>>>>>>> I would prefer merges to cherry-picks.
>>>>>>> Also, I think we should allow committers to commit to the RELEASE
>>>>> branch after discussing about it on dev@ and have RM closely monitor
>>> them.
>>>>>>> Any commit intended for 4.5 RELEASE should be checked in after
>>>>> discussion in the 4.5 Release branch and then merged to develop branch.
>>>>>>> 
>>>>>>> 
>>>>>>> ~Rajani
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>> 
>>>>>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
>>> left
>>>>> off
>>>>>>>> and then merge features from develop into 4.5.
>>>>>>>> 
>>>>>>>> Why don't we instead start 4.5 where master is now with the
>>> assumption
>>>>> that
>>>>>>>> since we are past Feature Freeze for 4.5 that master is stable
>>> enough?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
>>>>> daan.hoogland@gmail.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> so to start formulate a proposal:
>>>>>>>>> 
>>>>>>>>> all work shall be done in a new branch (it is advisable to prefix
>>> your
>>>>>>>>> branches with your id)
>>>>>>>>> when working, features will be cherry-picked/merged into the release
>>>>>>>>> branch they are for and next into master.
>>>>>>>>> hotfixes will be done in <branchname>-hotfixes
>>>>>>>>> 
>>>>>>>>> as transition we will
>>>>>>>>> 
>>>>>>>>> rename 'master' to 'develop'
>>>>>>>>> branch a new 'master' from '4.4'
>>>>>>>>> branch '4.5' from the new 'master'
>>>>>>>>> merge any features from the new 'develop' to '4.5' and 'master'
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <
>>> runseb@gmail.com
>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <runseb@gmail.com
>>>> 
>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <
>>> nate.gordon@appcore.com>
>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Let me ask the question, why have master be develop and a release
>>>>>>>>> branch be
>>>>>>>>>>>> "master"? If we are going to follow gitflow, why not just stick
>>>>> with
>>>>>>>>> the
>>>>>>>>>>>> norm? If master is the development branch, it might not be
>>> stable.
>>>>> I
>>>>>>>>> think
>>>>>>>>>>>> the goal here is that we have an obvious stable branch. Anyone
>>>>> could
>>>>>>>>> come
>>>>>>>>>>>> check out master and have the latest useable.
>>>>>>>>>>> 
>>>>>>>>>>> I am in favor of following the norm, so ideally master should be
>>> our
>>>>>>>>> stable branch (agreed).
>>>>>>>>>>> 
>>>>>>>>>>> The issue is with the transition.
>>>>>>>>>>> 
>>>>>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
>>>>> ideally
>>>>>>>>> we could start a stable branch of this tag and build up bug fix
>>>>> releases
>>>>>>>>> all the way to 4.5 from there.
>>>>>>>>>>> 
>>>>>>>>>>> But all features for 4.5 are already in master.
>>>>>>>>>>> 
>>>>>>>>>>> So if we create a 'develop' branch of master and stabilize
>>> 'master'
>>>>>>>>> then develop is now started from a stable tag (4.4.0).
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> *not* started from a stable tag, and merges will be tricky, no ?
>>>>>>>>>> 
>>>>>>>>>>> So what's the best way to flip ? There is most likely some git
>>> magic
>>>>>>>>> that can we do.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> The new git workflow and the transition process need to be part
>>> of a
>>>>>>>>> proposal that we get consensus on.
>>>>>>>>>>> 
>>>>>>>>>>> getting there :)
>>>>>>>>>>> 
>>>>>>>>>>> -seb
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If
>>>>> you
>>>>>>>>>>>> completely squash history, you lose a tremendous amount of
>>> context,
>>>>>>>>> which I
>>>>>>>>>>>> use extensively to figure out why a bug is the way it is. Only
>>>>> knowing
>>>>>>>>> that
>>>>>>>>>>>> the branch was merged at a given point in time doesn't give any
>>>>>>>>> context.
>>>>>>>>>>>> Seeing the individual commit history of the branch helps to
>>>>> preserve
>>>>>>>>> the
>>>>>>>>>>>> rationale for why the code was written the way it was. In theory
>>> if
>>>>>>>>> every
>>>>>>>>>>>> change starts out as a branch (feature, hotfix, release), then
>>> why
>>>>> not
>>>>>>>>> just
>>>>>>>>>>>> merge the branch once it is in a good and acceptable state?
>>>>>>>>>>>> 
>>>>>>>>>>>> I also agree with Mike that this will have to be a transition
>>> over
>>>>>>>>> time. It
>>>>>>>>>>>> will take some time to clean up master to the point where it can
>>> be
>>>>>>>>>>>> considered a solid stable branch. Possibly as part of the 4.5
>>>>> release.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
>>>>> runseb@gmail.com
>>>>>>>>>> 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <
>>>>> daan.hoogland@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Sebastien,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> It seems we can do what you are calling for is creating a
>>> branch
>>>>>>>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
>>>>>>>>> master,
>>>>>>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
>>>>> in a
>>>>>>>>>>>>>> branch make a fork of that branch and when that fork is working
>>>>> do a
>>>>>>>>>>>>>> cherry-pick. The -forward concept is now used for that but it
>>> is
>>>>>>>>>>>>>> broken because more then for one piece of work there are
>>> commits
>>>>> on
>>>>>>>>>>>>>> it. This caused me conflicts during the release. Especially
>>>>> painfull
>>>>>>>>>>>>>> as not all was intended to get into the release. We can create
>>>>> this
>>>>>>>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
>>>>>>>>> changes.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Yes, that's what I am thinking about too, so +1
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Our master would become the -develop- in gitflow terms
>>>>>>>>>>>>> The release branch you mention would become the -master- in
>>>>> gitflow
>>>>>>>>> terms
>>>>>>>>>>>>> 
>>>>>>>>>>>>> If we start now, indeed we can create 'release' from 4.4 release
>>>>> tag
>>>>>>>>>>>>> (voted and shipped).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> That means that to create 4.5 we will need to merge features
>>> back
>>>>> into
>>>>>>>>>>>>> 'release'. it might be messy because some of those features are
>>>>>>>>> already in
>>>>>>>>>>>>> our current master.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> But all of this will keep 'release' clean (we can keep track of
>>>>> bugs
>>>>>>>>> and
>>>>>>>>>>>>> features that are in it in CHANGES file etc..)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> There is a question of control. Do we allow all committers to
>>>>> manage
>>>>>>>>>>>>>> the release? I am for that but can imagine not everybody is.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> At first I would say that only the RM can commit to 'release'.
>>> As
>>>>> we
>>>>>>>>> get
>>>>>>>>>>>>> the CI in place  we could relax this and allow commits that pass
>>>>> the
>>>>>>>>> CI to
>>>>>>>>>>>>> get into 'release', but right now I would vote for a tighter
>>>>> control
>>>>>>>>> of
>>>>>>>>>>>>> 'release'.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> rule number 1 will be: you are going to do something to the
>>>>> code, you
>>>>>>>>>>>>>> start by creating a branch.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> right?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
>>>>>>>>> runseb@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <
>>>>> sam.schmit@appcore.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I've been a developer for a handful of years and have had my
>>>>> share
>>>>>>>>> of
>>>>>>>>>>>>>>>> experience with different version control systems.  I've used
>>>>> (for
>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Each of these solutions offers their own unique set of
>>>>> features,
>>>>>>>>>>>>> strengths
>>>>>>>>>>>>>>>> and weaknesses.  As there are so many systems that are good
>>> at
>>>>>>>>> specific
>>>>>>>>>>>>>>>> things, it seems best to use the features that the chosen
>>>>> system is
>>>>>>>>>>>>> best at.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Git is great at branching, merging and using that structure
>>> to
>>>>>>>>>>>>> maintain and
>>>>>>>>>>>>>>>> control how changes get into the primary branches.  Git tools
>>>>> even
>>>>>>>>> make
>>>>>>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
>>>>>>>>> branching
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to
>>>>> NOT
>>>>>>>>> make
>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>> of these built-in capabilities.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> In addition to that, I know that the current method of change
>>>>>>>>>>>>> management is
>>>>>>>>>>>>>>>> incredibly frustrating to work with, and works directly
>>>>> against the
>>>>>>>>>>>>> way a
>>>>>>>>>>>>>>>> typical Git user would expect it to be structured.  I should
>>>>> NEVER
>>>>>>>>> have
>>>>>>>>>>>>>>>> problem compiling and running something on master.  I should
>>>>> not
>>>>>>>>> have
>>>>>>>>>>>>>>>> problems building anything on a release branch.  A
>>>>> feature/bugfix
>>>>>>>>>>>>> branch is
>>>>>>>>>>>>>>>> where things can be, and often are, broken or unstable.
>>> There
>>>>> have
>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>> many times working in Cloudstack where I've had to search
>>> for a
>>>>>>>>> stable
>>>>>>>>>>>>>>>> revision on master, and that's just plain wrong.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I do realize that having this many developers working on so
>>>>> many
>>>>>>>>>>>>> features
>>>>>>>>>>>>>>>> and bugfixes will result in a large number of branches.  I
>>>>> don't
>>>>>>>>>>>>> believe
>>>>>>>>>>>>>>>> this is a good argument against using a branching method,
>>>>> though -
>>>>>>>>> I
>>>>>>>>>>>>>>>> believe that the current system is even more confusing and
>>>>>>>>> difficult
>>>>>>>>>>>>> to use.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I could pontificate on change management quite a bit more,
>>> but
>>>>> my
>>>>>>>>>>>>> opinion
>>>>>>>>>>>>>>>> in summary would basically be:  use Git the way it was meant
>>>>> to be
>>>>>>>>>>>>> used,
>>>>>>>>>>>>>>>> and things will be better.  Just my two cents.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Sam
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Sam, I think we are in agreement (at least with folks who
>>>>> responded
>>>>>>>>> to
>>>>>>>>>>>>> this thread).
>>>>>>>>>>>>>>> Or maybe I am not reading your mail right and you don't agree
>>>>> with
>>>>>>>>> Leo ?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> My own take and reason for calling for a change we are
>>> currently
>>>>>>>>> doing
>>>>>>>>>>>>> things is mostly due to the way we release.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I would like to see a stable master (and I think we are in
>>>>> agreement
>>>>>>>>>>>>> with that).
>>>>>>>>>>>>>>> That means that development should not happen on master and
>>> that
>>>>>>>>> every
>>>>>>>>>>>>> commit that lands on master should be shippable.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I personally have no issues with cherry-picking. So I would be
>>>>> fine
>>>>>>>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
>>>>>>>>>>>>>>> The end result is that the next commit on master would still
>>>>> mean
>>>>>>>>>>>>> master is shippable/releasable.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> If we agree with this basic concept. The question becomes how
>>>>> do we
>>>>>>>>> get
>>>>>>>>>>>>> there, considering that master is now full of dev work and
>>>>> potential
>>>>>>>>> bug.
>>>>>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
>>>>> previous
>>>>>>>>>>>>> release branches.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our
>>>>> way
>>>>>>>>> back,
>>>>>>>>>>>>> merging the new features that are already in master into the new
>>>>>>>>> master
>>>>>>>>>>>>> (based on 4.4).
>>>>>>>>>>>>>>> This could be quite complicated but we need to do it (or
>>>>> something
>>>>>>>>> like
>>>>>>>>>>>>> it).
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> To move forward, we should make a proposal to the list and
>>> call
>>>>> for
>>>>>>>>> a
>>>>>>>>>>>>> vote.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Any takers to start a wiki page proposing a new git process
>>> and
>>>>> how
>>>>>>>>> we
>>>>>>>>>>>>> could move to it (transition path) ?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> -Sebastien
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>>>>>>>>>>>>> LSimons@schubergphilis.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Hey folks,
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
>>>>> implement
>>>>>>>>> this?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
>>>>>>>>>>>>> committer so
>>>>>>>>>>>>>>>>> its not that practical for me to volunteer!
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> which might be easier to read.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Similarly, the git-flow scripts that help out with
>>>>> implementing
>>>>>>>>> this
>>>>>>>>>>>>> stuff
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> https://github.com/nvie/gitflow
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> they also describe the relationship between gitflow and
>>>>> dealing
>>>>>>>>> with
>>>>>>>>>>>>>>>>> multiple remotes
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
>>>>> support
>>>>>>>>> for
>>>>>>>>>>>>>>>>> git-flow
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> http://www.sourcetreeapp.com/
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Because cloudstack currently is full of rebasing and
>>>>> squashing and
>>>>>>>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
>>>>>>>>> visualization
>>>>>>>>>>>>> tool
>>>>>>>>>>>>>>>>> (like this or gitk or ...) right now, but it would be
>>> *great*
>>>>> to
>>>>>>>>> have
>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>> forward.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> cheers,
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Leo
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
>>>>> runseb@gmail.com
>>>>>>>>>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I would like to re-start this discussion.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Thinking about our release procedure, we clearly need more
>>>>> tests
>>>>>>>>> and
>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> CI. However it looks like this is going to take some time.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
>>>>>>>>> agreeing
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just
>>>>> need to
>>>>>>>>>>>>> agree on
>>>>>>>>>>>>>>>>> the git workflow.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Right now Master is really a development branch, we should
>>>>> make
>>>>>>>>> it a
>>>>>>>>>>>>>>>>> stable branch for production with very few commits.
>>>>>>>>>>>>>>>>>> This does not mean that we would release less, in contrary
>>>>> this
>>>>>>>>> would
>>>>>>>>>>>>>>>>> ensure that a commit to master means it's a production
>>>>> release.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back
>>>>> to
>>>>>>>>>>>>> Rajani's
>>>>>>>>>>>>>>>>> point) everything is based on merges.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I am of the opinion that git flow provides a nice process.
>>> It
>>>>>>>>>>>>> basically
>>>>>>>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
>>>>>>>>> releases
>>>>>>>>>>>>>>>>> branches are branched off of that and merged into master and
>>>>> back
>>>>>>>>> into
>>>>>>>>>>>>>>>>> develop….etc
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Please read [1] it's a good read.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> And let's discuss,
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> [1]
>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> -Sebastien
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> There is also the problem of cherry-picking.
>>>>>>>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches
>>>>> for
>>>>>>>>> each
>>>>>>>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches.
>>>>> which
>>>>>>>>> means
>>>>>>>>>>>>>>>>> distinct commits for each branch and I don’t easily know
>>>>> which all
>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>> my commit exists unless I do grep.
>>>>>>>>>>>>>>>>>>> if we follow merging strategy properly, apart from the
>>> first
>>>>>>>>> merge
>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> the branch, everything else on top of it should be a
>>> painless
>>>>>>>>> merge.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> I think many of the bullet points are what we are
>>> currently
>>>>>>>>> doing
>>>>>>>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to
>>>>> stay
>>>>>>>>> in
>>>>>>>>>>>>> sync
>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>> master, no back-merging). I also think that much of what
>>>>> we do
>>>>>>>>> now
>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>>>>>>> the way it is simply because there *are* vast changes
>>>>> between
>>>>>>>>>>>>> versions.
>>>>>>>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the
>>>>> time.
>>>>>>>>> If
>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine,
>>> but
>>>>> some
>>>>>>>>>>>>> quick
>>>>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with
>>>>> having
>>>>>>>>> single
>>>>>>>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits
>>>>> where
>>>>>>>>> each
>>>>>>>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to
>>> remember
>>>>>>>>> why we
>>>>>>>>>>>>> went
>>>>>>>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
>>>>>>>>> somewhere, but
>>>>>>>>>>>>>>>>> one of
>>>>>>>>>>>>>>>>>>>> the nice things it provides is the ability for the
>>> release
>>>>>>>>> manager
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> control what changes are made during code freeze while
>>>>> giving
>>>>>>>>>>>>> people a
>>>>>>>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not
>>> always
>>>>>>>>>>>>> followed).
>>>>>>>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have
>>>>> their
>>>>>>>>> own
>>>>>>>>>>>>>>>>> repo and
>>>>>>>>>>>>>>>>>>>> issue pull requests for bugfixes?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
>>>>>>>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a
>>> empty
>>>>>>>>>>>>>>>>> merge(merge -s
>>>>>>>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
>>>>>>>>> bring in
>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>>>>>> changes.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a
>>> major
>>>>>>>>>>>>> rewrite, we
>>>>>>>>>>>>>>>>>>>>> could stop merging to that branch and above and make the
>>>>> fix
>>>>>>>>>>>>> manually.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>>>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a
>>>>> particular fix
>>>>>>>>>>>>> for an
>>>>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does
>>>>> happen.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to
>>> branch
>>>>> x"
>>>>>>>>> in
>>>>>>>>>>>>> SVN
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
>>>>>>>>> branch(es).
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>>>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
>>>>> versions, or
>>>>>>>>>>>>> has to
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
>>>>> changed?
>>>>>>>>>>>>> Don't
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after
>>>>> that?
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> Stephen Turner
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
>>>>> mike.tutkowski@solidfire.com]
>>>>>>>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
>>>>>>>>> consider.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be
>>> error
>>>>>>>>> prone
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
>>>>> applicable
>>>>>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks
>>> are
>>>>>>>>>>>>> related.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to
>>>>> see
>>>>>>>>> if you
>>>>>>>>>>>>>>>>>>>>> checked a
>>>>>>>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In
>>>>> such a
>>>>>>>>>>>>>>>>> situation,
>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
>>>>> check-in
>>>>>>>>>>>>> was no
>>>>>>>>>>>>>>>>>>>>> longer
>>>>>>>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to
>>>>> mark
>>>>>>>>> it as
>>>>>>>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure
>>>>> about
>>>>>>>>> Git).
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the
>>>>> *forward
>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all
>>>>> releases the
>>>>>>>>>>>>> commit
>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also,
>>> as a
>>>>>>>>>>>>>>>>> contributor, I
>>>>>>>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
>>>>>>>>> cleanly
>>>>>>>>>>>>>>>>> apply on
>>>>>>>>>>>>>>>>>>>>>>>>> different branches.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is
>>> what I
>>>>>>>>>>>>> propose.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major
>>> release(ex:
>>>>>>>>> 4.3.x,
>>>>>>>>>>>>>>>>> 4.4.x,
>>>>>>>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>>>>>>>>>>>>> accordingly
>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>>> the respective branches.
>>>>>>>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed.
>>>>> Many
>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when
>>> we
>>>>>>>>>>>>> cherry-pick,
>>>>>>>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
>>>>>>>>> change or
>>>>>>>>>>>>>>>>> fix and
>>>>>>>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
>>>>> release
>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They
>>> should
>>>>> be
>>>>>>>>>>>>>>>>> merged(either
>>>>>>>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
>>>>>>>>> trackable
>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>> git branch --contains
>>>>>>>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
>>>>> release
>>>>>>>>>>>>> uptill
>>>>>>>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches
>>> master.
>>>>>>>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next
>>> time
>>>>> a
>>>>>>>>> new
>>>>>>>>>>>>> commit
>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
>>>>> master
>>>>>>>>> to
>>>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
>>>>>>>>> proactively
>>>>>>>>>>>>>>>>> take
>>>>>>>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
>>>>> master
>>>>>>>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
>>>>> master on
>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>>>>> complete through a merge.
>>>>>>>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
>>>>> release
>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any
>>> minor
>>>>>>>>> release)
>>>>>>>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
>>>>> information
>>>>>>>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>;
>>> reviewed
>>>>> by
>>>>>>>>>>>>>>>>>>>>> <committer>
>>>>>>>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
>>>>> freeze),
>>>>>>>>>>>>> any bug
>>>>>>>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
>>>>>>>>> release(4.4)
>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
>>>>> branch.
>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be
>>> using
>>>>>>>>> jira
>>>>>>>>>>>>> vote?)
>>>>>>>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another
>>>>> branch
>>>>>>>>>>>>>>>>>>>>> maintenance.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Ref:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> ~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
>>>>>> *™*
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> *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
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> *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.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> 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>*™*
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> 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>*™*
>>> 
>>> 
> 
> 
> 
> -- 
> Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

Rightful question Erik,

Rajani mentioned that release branches will be deleted. This will only
happen once the release is no longer supported. Any hotfix branch will
still have to merged on that (and master possibly) until we stop
supporting that branch.

On the other hand you can branch from any commit.

btw 4.4.1 is a bad example of you as we will still maintain that
without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.

On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber <te...@gmail.com> wrote:
> This is out of my git league, but how do you handle minor versions that way?
>
> Assuming 4.8.0 is the latest stable release and HEAD on master.
>
> Then you want to release 4.4.1.
>
> First of all can you develop bugfixes for 4.4 along the way, when both
> develop and master HEAD might be hugely different?
>
> Second, can you commit  behind HEAD? You don't want the 4.4.1 release
> instead of 4.8.0 to be HEAD
>
> Someone might have good solutions to this, but if not I would propose to
> keep the release branches for future bugfixes.
>
> Erik
> 25. juli 2014 06:02 skrev "Rajani Karuturi" <Ra...@citrix.com>
> følgende:
>
>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <mi...@solidfire.com>
>> wrote:
>>
>> > I believe I agree with these steps.
>> >
>> > A couple questions:
>> >
>> > Is 'master' simply always going to be equal to what's the most recent
>> > version of the code that's in production?
>>
>> I think so. master will always be at the latest release and all the
>> previous releases properly tagged. The release branches would be deleted
>> once release is done.
>>
>> >
>> > Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
>> > into RELEASE-4.5?
>> >
>>
>> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
>> should be done on the 4.5 branch.
>>
>>
>>
>> ~Rajani
>>
>>
>> >
>> > On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
>> > Rajani.Karuturi@citrix.com> wrote:
>> >
>> >>
>> >> Hi Daan,
>> >> here is what i propose:
>> >>
>> >> 1. rename 'master' to 'develop’
>> >> 2. branch a new 'master' from '4.4’
>> >> 3. branch 'RELEASE-4.5' from the develop
>> >> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>> >>
>> >> RELEASE-4.6 branch should be off develop as all the feature branches
>> would
>> >> be merged there before freeze for 4.6 and would be merged to master when
>> >> the release is voted.
>> >>
>> >> The other question I have is in the step:4. how are we going to manage
>> >> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is
>> done)
>> >>
>> >> ~Rajani
>> >>
>> >>
>> >>
>> >> On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com>
>> >> wrote:
>> >>
>> >>> Mike, Rajani,
>> >>>
>> >>> Sebastien's point was that the current 4.4 is the closest we have to a
>> >>> releasable branch. I don't mind enting on master but it will require
>> >>> more fixing. In general all of this will require some RM work of all
>> >>> committers. Please ammend my little proposal if you will.
>> >>>
>> >>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
>> >>> <Ra...@citrix.com> wrote:
>> >>>> I agree with mike. I think we should start 4.5 from where master is
>> now
>> >>>> Also create a develop branch from master and continue future work for
>> >> 4.6 there.
>> >>>>
>> >>>> I am not clear on how the release branches are going to be maintained.
>> >>>> Are we saying we would create 4.5-RELEASE branch which is essentially
>> >> same as our current -FORWARD branch and continue cherry-picking?
>> >>>>
>> >>>> I would prefer merges to cherry-picks.
>> >>>> Also, I think we should allow committers to commit to the RELEASE
>> >> branch after discussing about it on dev@ and have RM closely monitor
>> them.
>> >>>> Any commit intended for 4.5 RELEASE should be checked in after
>> >> discussion in the 4.5 Release branch and then merged to develop branch.
>> >>>>
>> >>>>
>> >>>> ~Rajani
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
>> >> mike.tutkowski@solidfire.com> wrote:
>> >>>>
>> >>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
>> left
>> >> off
>> >>>>> and then merge features from develop into 4.5.
>> >>>>>
>> >>>>> Why don't we instead start 4.5 where master is now with the
>> assumption
>> >> that
>> >>>>> since we are past Feature Freeze for 4.5 that master is stable
>> enough?
>> >>>>>
>> >>>>>
>> >>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
>> >> daan.hoogland@gmail.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> so to start formulate a proposal:
>> >>>>>>
>> >>>>>> all work shall be done in a new branch (it is advisable to prefix
>> your
>> >>>>>> branches with your id)
>> >>>>>> when working, features will be cherry-picked/merged into the release
>> >>>>>> branch they are for and next into master.
>> >>>>>> hotfixes will be done in <branchname>-hotfixes
>> >>>>>>
>> >>>>>> as transition we will
>> >>>>>>
>> >>>>>> rename 'master' to 'develop'
>> >>>>>> branch a new 'master' from '4.4'
>> >>>>>> branch '4.5' from the new 'master'
>> >>>>>> merge any features from the new 'develop' to '4.5' and 'master'
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <
>> runseb@gmail.com
>> >>>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <runseb@gmail.com
>> >
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <
>> nate.gordon@appcore.com>
>> >>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> Let me ask the question, why have master be develop and a release
>> >>>>>> branch be
>> >>>>>>>>> "master"? If we are going to follow gitflow, why not just stick
>> >> with
>> >>>>>> the
>> >>>>>>>>> norm? If master is the development branch, it might not be
>> stable.
>> >> I
>> >>>>>> think
>> >>>>>>>>> the goal here is that we have an obvious stable branch. Anyone
>> >> could
>> >>>>>> come
>> >>>>>>>>> check out master and have the latest useable.
>> >>>>>>>>
>> >>>>>>>> I am in favor of following the norm, so ideally master should be
>> our
>> >>>>>> stable branch (agreed).
>> >>>>>>>>
>> >>>>>>>> The issue is with the transition.
>> >>>>>>>>
>> >>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
>> >> ideally
>> >>>>>> we could start a stable branch of this tag and build up bug fix
>> >> releases
>> >>>>>> all the way to 4.5 from there.
>> >>>>>>>>
>> >>>>>>>> But all features for 4.5 are already in master.
>> >>>>>>>>
>> >>>>>>>> So if we create a 'develop' branch of master and stabilize
>> 'master'
>> >>>>>> then develop is now started from a stable tag (4.4.0).
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>> *not* started from a stable tag, and merges will be tricky, no ?
>> >>>>>>>
>> >>>>>>>> So what's the best way to flip ? There is most likely some git
>> magic
>> >>>>>> that can we do.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> The new git workflow and the transition process need to be part
>> of a
>> >>>>>> proposal that we get consensus on.
>> >>>>>>>>
>> >>>>>>>> getting there :)
>> >>>>>>>>
>> >>>>>>>> -seb
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If
>> >> you
>> >>>>>>>>> completely squash history, you lose a tremendous amount of
>> context,
>> >>>>>> which I
>> >>>>>>>>> use extensively to figure out why a bug is the way it is. Only
>> >> knowing
>> >>>>>> that
>> >>>>>>>>> the branch was merged at a given point in time doesn't give any
>> >>>>>> context.
>> >>>>>>>>> Seeing the individual commit history of the branch helps to
>> >> preserve
>> >>>>>> the
>> >>>>>>>>> rationale for why the code was written the way it was. In theory
>> if
>> >>>>>> every
>> >>>>>>>>> change starts out as a branch (feature, hotfix, release), then
>> why
>> >> not
>> >>>>>> just
>> >>>>>>>>> merge the branch once it is in a good and acceptable state?
>> >>>>>>>>>
>> >>>>>>>>> I also agree with Mike that this will have to be a transition
>> over
>> >>>>>> time. It
>> >>>>>>>>> will take some time to clean up master to the point where it can
>> be
>> >>>>>>>>> considered a solid stable branch. Possibly as part of the 4.5
>> >> release.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
>> >> runseb@gmail.com
>> >>>>>>>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <
>> >> daan.hoogland@gmail.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> Sebastien,
>> >>>>>>>>>>>
>> >>>>>>>>>>> It seems we can do what you are calling for is creating a
>> branch
>> >>>>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
>> >>>>>> master,
>> >>>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
>> >> in a
>> >>>>>>>>>>> branch make a fork of that branch and when that fork is working
>> >> do a
>> >>>>>>>>>>> cherry-pick. The -forward concept is now used for that but it
>> is
>> >>>>>>>>>>> broken because more then for one piece of work there are
>> commits
>> >> on
>> >>>>>>>>>>> it. This caused me conflicts during the release. Especially
>> >> painfull
>> >>>>>>>>>>> as not all was intended to get into the release. We can create
>> >> this
>> >>>>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
>> >>>>>> changes.
>> >>>>>>>>>>
>> >>>>>>>>>> Yes, that's what I am thinking about too, so +1
>> >>>>>>>>>>
>> >>>>>>>>>> Our master would become the -develop- in gitflow terms
>> >>>>>>>>>> The release branch you mention would become the -master- in
>> >> gitflow
>> >>>>>> terms
>> >>>>>>>>>>
>> >>>>>>>>>> If we start now, indeed we can create 'release' from 4.4 release
>> >> tag
>> >>>>>>>>>> (voted and shipped).
>> >>>>>>>>>>
>> >>>>>>>>>> That means that to create 4.5 we will need to merge features
>> back
>> >> into
>> >>>>>>>>>> 'release'. it might be messy because some of those features are
>> >>>>>> already in
>> >>>>>>>>>> our current master.
>> >>>>>>>>>>
>> >>>>>>>>>> But all of this will keep 'release' clean (we can keep track of
>> >> bugs
>> >>>>>> and
>> >>>>>>>>>> features that are in it in CHANGES file etc..)
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> There is a question of control. Do we allow all committers to
>> >> manage
>> >>>>>>>>>>> the release? I am for that but can imagine not everybody is.
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> At first I would say that only the RM can commit to 'release'.
>> As
>> >> we
>> >>>>>> get
>> >>>>>>>>>> the CI in place  we could relax this and allow commits that pass
>> >> the
>> >>>>>> CI to
>> >>>>>>>>>> get into 'release', but right now I would vote for a tighter
>> >> control
>> >>>>>> of
>> >>>>>>>>>> 'release'.
>> >>>>>>>>>>
>> >>>>>>>>>>> rule number 1 will be: you are going to do something to the
>> >> code, you
>> >>>>>>>>>>> start by creating a branch.
>> >>>>>>>>>>>
>> >>>>>>>>>>> right?
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
>> >>>>>> runseb@gmail.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <
>> >> sam.schmit@appcore.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> Hey everyone,
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I've been a developer for a handful of years and have had my
>> >> share
>> >>>>>> of
>> >>>>>>>>>>>>> experience with different version control systems.  I've used
>> >> (for
>> >>>>>>>>>> better
>> >>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Each of these solutions offers their own unique set of
>> >> features,
>> >>>>>>>>>> strengths
>> >>>>>>>>>>>>> and weaknesses.  As there are so many systems that are good
>> at
>> >>>>>> specific
>> >>>>>>>>>>>>> things, it seems best to use the features that the chosen
>> >> system is
>> >>>>>>>>>> best at.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Git is great at branching, merging and using that structure
>> to
>> >>>>>>>>>> maintain and
>> >>>>>>>>>>>>> control how changes get into the primary branches.  Git tools
>> >> even
>> >>>>>> make
>> >>>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
>> >>>>>> branching
>> >>>>>>>>>> and
>> >>>>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to
>> >> NOT
>> >>>>>> make
>> >>>>>>>>>> use
>> >>>>>>>>>>>>> of these built-in capabilities.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> In addition to that, I know that the current method of change
>> >>>>>>>>>> management is
>> >>>>>>>>>>>>> incredibly frustrating to work with, and works directly
>> >> against the
>> >>>>>>>>>> way a
>> >>>>>>>>>>>>> typical Git user would expect it to be structured.  I should
>> >> NEVER
>> >>>>>> have
>> >>>>>>>>>>>>> problem compiling and running something on master.  I should
>> >> not
>> >>>>>> have
>> >>>>>>>>>>>>> problems building anything on a release branch.  A
>> >> feature/bugfix
>> >>>>>>>>>> branch is
>> >>>>>>>>>>>>> where things can be, and often are, broken or unstable.
>>  There
>> >> have
>> >>>>>>>>>> been
>> >>>>>>>>>>>>> many times working in Cloudstack where I've had to search
>> for a
>> >>>>>> stable
>> >>>>>>>>>>>>> revision on master, and that's just plain wrong.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I do realize that having this many developers working on so
>> >> many
>> >>>>>>>>>> features
>> >>>>>>>>>>>>> and bugfixes will result in a large number of branches.  I
>> >> don't
>> >>>>>>>>>> believe
>> >>>>>>>>>>>>> this is a good argument against using a branching method,
>> >> though -
>> >>>>>> I
>> >>>>>>>>>>>>> believe that the current system is even more confusing and
>> >>>>>> difficult
>> >>>>>>>>>> to use.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I could pontificate on change management quite a bit more,
>> but
>> >> my
>> >>>>>>>>>> opinion
>> >>>>>>>>>>>>> in summary would basically be:  use Git the way it was meant
>> >> to be
>> >>>>>>>>>> used,
>> >>>>>>>>>>>>> and things will be better.  Just my two cents.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Sam
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Sam, I think we are in agreement (at least with folks who
>> >> responded
>> >>>>>> to
>> >>>>>>>>>> this thread).
>> >>>>>>>>>>>> Or maybe I am not reading your mail right and you don't agree
>> >> with
>> >>>>>> Leo ?
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> My own take and reason for calling for a change we are
>> currently
>> >>>>>> doing
>> >>>>>>>>>> things is mostly due to the way we release.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I would like to see a stable master (and I think we are in
>> >> agreement
>> >>>>>>>>>> with that).
>> >>>>>>>>>>>> That means that development should not happen on master and
>> that
>> >>>>>> every
>> >>>>>>>>>> commit that lands on master should be shippable.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I personally have no issues with cherry-picking. So I would be
>> >> fine
>> >>>>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
>> >>>>>>>>>>>> The end result is that the next commit on master would still
>> >> mean
>> >>>>>>>>>> master is shippable/releasable.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> If we agree with this basic concept. The question becomes how
>> >> do we
>> >>>>>> get
>> >>>>>>>>>> there, considering that master is now full of dev work and
>> >> potential
>> >>>>>> bug.
>> >>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
>> >> previous
>> >>>>>>>>>> release branches.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our
>> >> way
>> >>>>>> back,
>> >>>>>>>>>> merging the new features that are already in master into the new
>> >>>>>> master
>> >>>>>>>>>> (based on 4.4).
>> >>>>>>>>>>>> This could be quite complicated but we need to do it (or
>> >> something
>> >>>>>> like
>> >>>>>>>>>> it).
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> To move forward, we should make a proposal to the list and
>> call
>> >> for
>> >>>>>> a
>> >>>>>>>>>> vote.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Any takers to start a wiki page proposing a new git process
>> and
>> >> how
>> >>>>>> we
>> >>>>>>>>>> could move to it (transition path) ?
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> -Sebastien
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>> >>>>>>>>>> LSimons@schubergphilis.com>
>> >>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Hey folks,
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
>> >> implement
>> >>>>>> this?
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
>> >>>>>>>>>> committer so
>> >>>>>>>>>>>>>> its not that practical for me to volunteer!
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> which might be easier to read.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Similarly, the git-flow scripts that help out with
>> >> implementing
>> >>>>>> this
>> >>>>>>>>>> stuff
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> https://github.com/nvie/gitflow
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> they also describe the relationship between gitflow and
>> >> dealing
>> >>>>>> with
>> >>>>>>>>>>>>>> multiple remotes
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
>> >> support
>> >>>>>> for
>> >>>>>>>>>>>>>> git-flow
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> http://www.sourcetreeapp.com/
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Because cloudstack currently is full of rebasing and
>> >> squashing and
>> >>>>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
>> >>>>>> visualization
>> >>>>>>>>>> tool
>> >>>>>>>>>>>>>> (like this or gitk or ...) right now, but it would be
>> *great*
>> >> to
>> >>>>>> have
>> >>>>>>>>>> going
>> >>>>>>>>>>>>>> forward.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> cheers,
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Leo
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
>> >> runseb@gmail.com
>> >>>>>>>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I would like to re-start this discussion.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Thinking about our release procedure, we clearly need more
>> >> tests
>> >>>>>> and
>> >>>>>>>>>> a
>> >>>>>>>>>>>>>> CI. However it looks like this is going to take some time.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
>> >>>>>> agreeing
>> >>>>>>>>>> to
>> >>>>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just
>> >> need to
>> >>>>>>>>>> agree on
>> >>>>>>>>>>>>>> the git workflow.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Right now Master is really a development branch, we should
>> >> make
>> >>>>>> it a
>> >>>>>>>>>>>>>> stable branch for production with very few commits.
>> >>>>>>>>>>>>>>> This does not mean that we would release less, in contrary
>> >> this
>> >>>>>> would
>> >>>>>>>>>>>>>> ensure that a commit to master means it's a production
>> >> release.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back
>> >> to
>> >>>>>>>>>> Rajani's
>> >>>>>>>>>>>>>> point) everything is based on merges.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I am of the opinion that git flow provides a nice process.
>> It
>> >>>>>>>>>> basically
>> >>>>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
>> >>>>>> releases
>> >>>>>>>>>>>>>> branches are branched off of that and merged into master and
>> >> back
>> >>>>>> into
>> >>>>>>>>>>>>>> develop….etc
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Please read [1] it's a good read.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> And let's discuss,
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> [1]
>> http://nvie.com/posts/a-successful-git-branching-model/
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> -Sebastien
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>> >>>>>>>>>> Rajani.Karuturi@citrix.com>
>> >>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> There is also the problem of cherry-picking.
>> >>>>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches
>> >> for
>> >>>>>> each
>> >>>>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches.
>> >> which
>> >>>>>> means
>> >>>>>>>>>>>>>> distinct commits for each branch and I don’t easily know
>> >> which all
>> >>>>>>>>>> branches
>> >>>>>>>>>>>>>> my commit exists unless I do grep.
>> >>>>>>>>>>>>>>>> if we follow merging strategy properly, apart from the
>> first
>> >>>>>> merge
>> >>>>>>>>>> of
>> >>>>>>>>>>>>>> the branch, everything else on top of it should be a
>> painless
>> >>>>>> merge.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> ~Rajani
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
>> >>>>>> wrote:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> I think many of the bullet points are what we are
>> currently
>> >>>>>> doing
>> >>>>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to
>> >> stay
>> >>>>>> in
>> >>>>>>>>>> sync
>> >>>>>>>>>>>>>> with
>> >>>>>>>>>>>>>>>>> master, no back-merging). I also think that much of what
>> >> we do
>> >>>>>> now
>> >>>>>>>>>> is
>> >>>>>>>>>>>>>> done
>> >>>>>>>>>>>>>>>>> the way it is simply because there *are* vast changes
>> >> between
>> >>>>>>>>>> versions.
>> >>>>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the
>> >> time.
>> >>>>>> If
>> >>>>>>>>>> its
>> >>>>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine,
>> but
>> >> some
>> >>>>>>>>>> quick
>> >>>>>>>>>>>>>> tests
>> >>>>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with
>> >> having
>> >>>>>> single
>> >>>>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits
>> >> where
>> >>>>>> each
>> >>>>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to
>> remember
>> >>>>>> why we
>> >>>>>>>>>> went
>> >>>>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
>> >>>>>> somewhere, but
>> >>>>>>>>>>>>>> one of
>> >>>>>>>>>>>>>>>>> the nice things it provides is the ability for the
>> release
>> >>>>>> manager
>> >>>>>>>>>> to
>> >>>>>>>>>>>>>>>>> control what changes are made during code freeze while
>> >> giving
>> >>>>>>>>>> people a
>> >>>>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not
>> always
>> >>>>>>>>>> followed).
>> >>>>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have
>> >> their
>> >>>>>> own
>> >>>>>>>>>>>>>> repo and
>> >>>>>>>>>>>>>>>>> issue pull requests for bugfixes?
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>> >>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>> >>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
>> >>>>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> ~Rajani
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>> >>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>> >>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a
>> empty
>> >>>>>>>>>>>>>> merge(merge -s
>> >>>>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
>> >>>>>> bring in
>> >>>>>>>>>> any
>> >>>>>>>>>>>>>>>>>> changes.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a
>> major
>> >>>>>>>>>> rewrite, we
>> >>>>>>>>>>>>>>>>>> could stop merging to that branch and above and make the
>> >> fix
>> >>>>>>>>>> manually.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> ~Rajani
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>> >>>>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a
>> >> particular fix
>> >>>>>>>>>> for an
>> >>>>>>>>>>>>>> old
>> >>>>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does
>> >> happen.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to
>> branch
>> >> x"
>> >>>>>> in
>> >>>>>>>>>> SVN
>> >>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>>> then
>> >>>>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
>> >>>>>> branch(es).
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>> >>>>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
>> >>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
>> >> versions, or
>> >>>>>>>>>> has to
>> >>>>>>>>>>>>>> be
>> >>>>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
>> >> changed?
>> >>>>>>>>>> Don't
>> >>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after
>> >> that?
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>>>>>> Stephen Turner
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>> >>>>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
>> >> mike.tutkowski@solidfire.com]
>> >>>>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>> >>>>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>> >>>>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
>> >>>>>> consider.
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be
>> error
>> >>>>>> prone
>> >>>>>>>>>> in
>> >>>>>>>>>>>>>> that
>> >>>>>>>>>>>>>>>>>> it's
>> >>>>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
>> >> applicable
>> >>>>>>>>>>>>>> branches
>> >>>>>>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks
>> are
>> >>>>>>>>>> related.
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to
>> >> see
>> >>>>>> if you
>> >>>>>>>>>>>>>>>>>> checked a
>> >>>>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In
>> >> such a
>> >>>>>>>>>>>>>> situation,
>> >>>>>>>>>>>>>>>>>> you
>> >>>>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
>> >> check-in
>> >>>>>>>>>> was no
>> >>>>>>>>>>>>>>>>>> longer
>> >>>>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to
>> >> mark
>> >>>>>> it as
>> >>>>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure
>> >> about
>> >>>>>> Git).
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>> >>>>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Hi all,
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the
>> >> *forward
>> >>>>>>>>>> branches
>> >>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all
>> >> releases the
>> >>>>>>>>>> commit
>> >>>>>>>>>>>>>> has
>> >>>>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also,
>> as a
>> >>>>>>>>>>>>>> contributor, I
>> >>>>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
>> >>>>>> cleanly
>> >>>>>>>>>>>>>> apply on
>> >>>>>>>>>>>>>>>>>>>>>> different branches.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is
>> what I
>> >>>>>>>>>> propose.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major
>> release(ex:
>> >>>>>> 4.3.x,
>> >>>>>>>>>>>>>> 4.4.x,
>> >>>>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>> >>>>>>>>>> accordingly
>> >>>>>>>>>>>>>> on
>> >>>>>>>>>>>>>>>>>>>>>> the respective branches.
>> >>>>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed.
>> >> Many
>> >>>>>>>>>> branches
>> >>>>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>> >>>>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when
>> we
>> >>>>>>>>>> cherry-pick,
>> >>>>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
>> >>>>>> change or
>> >>>>>>>>>>>>>> fix and
>> >>>>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>> >>>>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
>> >> release
>> >>>>>>>>>> branches
>> >>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They
>> should
>> >> be
>> >>>>>>>>>>>>>> merged(either
>> >>>>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
>> >>>>>> trackable
>> >>>>>>>>>>>>>> with
>> >>>>>>>>>>>>>>>>>>>>>> git branch --contains
>> >>>>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
>> >> release
>> >>>>>>>>>> uptill
>> >>>>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches
>> master.
>> >>>>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>> >>>>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>> >>>>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next
>> time
>> >> a
>> >>>>>> new
>> >>>>>>>>>> commit
>> >>>>>>>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>>>>>> done this will also get merged.
>> >>>>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
>> >> master
>> >>>>>> to
>> >>>>>>>>>>>>>> feature
>> >>>>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
>> >>>>>> proactively
>> >>>>>>>>>>>>>> take
>> >>>>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
>> >> master
>> >>>>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
>> >> master on
>> >>>>>>>>>> code
>> >>>>>>>>>>>>>>>>>>>>>> complete through a merge.
>> >>>>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
>> >> release
>> >>>>>>>>>> branches
>> >>>>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any
>> minor
>> >>>>>> release)
>> >>>>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
>> >> information
>> >>>>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>;
>> reviewed
>> >> by
>> >>>>>>>>>>>>>>>>>> <committer>
>> >>>>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>> >>>>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
>> >> freeze),
>> >>>>>>>>>> any bug
>> >>>>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
>> >>>>>> release(4.4)
>> >>>>>>>>>> only
>> >>>>>>>>>>>>>> on
>> >>>>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
>> >> branch.
>> >>>>>>>>>> This
>> >>>>>>>>>>>>>> can be
>> >>>>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be
>> using
>> >>>>>> jira
>> >>>>>>>>>> vote?)
>> >>>>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another
>> >> branch
>> >>>>>>>>>>>>>>>>>> maintenance.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Ref:
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>> >>>>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> ~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
>> >>> *™*
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>>>>> *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
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> *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.
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> 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>*™*
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> 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>*™*
>>
>>



-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

This is out of my git league, but how do you handle minor versions that way?

Assuming 4.8.0 is the latest stable release and HEAD on master.

Then you want to release 4.4.1.

First of all can you develop bugfixes for 4.4 along the way, when both
develop and master HEAD might be hugely different?

Second, can you commit  behind HEAD? You don't want the 4.4.1 release
instead of 4.8.0 to be HEAD

Someone might have good solutions to this, but if not I would propose to
keep the release branches for future bugfixes.

Erik
25. juli 2014 06:02 skrev "Rajani Karuturi" <Ra...@citrix.com>
følgende:

> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <mi...@solidfire.com>
> wrote:
>
> > I believe I agree with these steps.
> >
> > A couple questions:
> >
> > Is 'master' simply always going to be equal to what's the most recent
> > version of the code that's in production?
>
> I think so. master will always be at the latest release and all the
> previous releases properly tagged. The release branches would be deleted
> once release is done.
>
> >
> > Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
> > into RELEASE-4.5?
> >
>
> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
> should be done on the 4.5 branch.
>
>
>
> ~Rajani
>
>
> >
> > On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
> > Rajani.Karuturi@citrix.com> wrote:
> >
> >>
> >> Hi Daan,
> >> here is what i propose:
> >>
> >> 1. rename 'master' to 'develop’
> >> 2. branch a new 'master' from '4.4’
> >> 3. branch 'RELEASE-4.5' from the develop
> >> 4. merge 'RELEASE-4.5' to master once the release voting is done.
> >>
> >> RELEASE-4.6 branch should be off develop as all the feature branches
> would
> >> be merged there before freeze for 4.6 and would be merged to master when
> >> the release is voted.
> >>
> >> The other question I have is in the step:4. how are we going to manage
> >> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is
> done)
> >>
> >> ~Rajani
> >>
> >>
> >>
> >> On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com>
> >> wrote:
> >>
> >>> Mike, Rajani,
> >>>
> >>> Sebastien's point was that the current 4.4 is the closest we have to a
> >>> releasable branch. I don't mind enting on master but it will require
> >>> more fixing. In general all of this will require some RM work of all
> >>> committers. Please ammend my little proposal if you will.
> >>>
> >>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
> >>> <Ra...@citrix.com> wrote:
> >>>> I agree with mike. I think we should start 4.5 from where master is
> now
> >>>> Also create a develop branch from master and continue future work for
> >> 4.6 there.
> >>>>
> >>>> I am not clear on how the release branches are going to be maintained.
> >>>> Are we saying we would create 4.5-RELEASE branch which is essentially
> >> same as our current -FORWARD branch and continue cherry-picking?
> >>>>
> >>>> I would prefer merges to cherry-picks.
> >>>> Also, I think we should allow committers to commit to the RELEASE
> >> branch after discussing about it on dev@ and have RM closely monitor
> them.
> >>>> Any commit intended for 4.5 RELEASE should be checked in after
> >> discussion in the 4.5 Release branch and then merged to develop branch.
> >>>>
> >>>>
> >>>> ~Rajani
> >>>>
> >>>>
> >>>>
> >>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
> >> mike.tutkowski@solidfire.com> wrote:
> >>>>
> >>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
> left
> >> off
> >>>>> and then merge features from develop into 4.5.
> >>>>>
> >>>>> Why don't we instead start 4.5 where master is now with the
> assumption
> >> that
> >>>>> since we are past Feature Freeze for 4.5 that master is stable
> enough?
> >>>>>
> >>>>>
> >>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
> >> daan.hoogland@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> so to start formulate a proposal:
> >>>>>>
> >>>>>> all work shall be done in a new branch (it is advisable to prefix
> your
> >>>>>> branches with your id)
> >>>>>> when working, features will be cherry-picked/merged into the release
> >>>>>> branch they are for and next into master.
> >>>>>> hotfixes will be done in <branchname>-hotfixes
> >>>>>>
> >>>>>> as transition we will
> >>>>>>
> >>>>>> rename 'master' to 'develop'
> >>>>>> branch a new 'master' from '4.4'
> >>>>>> branch '4.5' from the new 'master'
> >>>>>> merge any features from the new 'develop' to '4.5' and 'master'
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <
> runseb@gmail.com
> >>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <runseb@gmail.com
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <
> nate.gordon@appcore.com>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Let me ask the question, why have master be develop and a release
> >>>>>> branch be
> >>>>>>>>> "master"? If we are going to follow gitflow, why not just stick
> >> with
> >>>>>> the
> >>>>>>>>> norm? If master is the development branch, it might not be
> stable.
> >> I
> >>>>>> think
> >>>>>>>>> the goal here is that we have an obvious stable branch. Anyone
> >> could
> >>>>>> come
> >>>>>>>>> check out master and have the latest useable.
> >>>>>>>>
> >>>>>>>> I am in favor of following the norm, so ideally master should be
> our
> >>>>>> stable branch (agreed).
> >>>>>>>>
> >>>>>>>> The issue is with the transition.
> >>>>>>>>
> >>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
> >> ideally
> >>>>>> we could start a stable branch of this tag and build up bug fix
> >> releases
> >>>>>> all the way to 4.5 from there.
> >>>>>>>>
> >>>>>>>> But all features for 4.5 are already in master.
> >>>>>>>>
> >>>>>>>> So if we create a 'develop' branch of master and stabilize
> 'master'
> >>>>>> then develop is now started from a stable tag (4.4.0).
> >>>>>>>>
> >>>>>>>
> >>>>>>> *not* started from a stable tag, and merges will be tricky, no ?
> >>>>>>>
> >>>>>>>> So what's the best way to flip ? There is most likely some git
> magic
> >>>>>> that can we do.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> The new git workflow and the transition process need to be part
> of a
> >>>>>> proposal that we get consensus on.
> >>>>>>>>
> >>>>>>>> getting there :)
> >>>>>>>>
> >>>>>>>> -seb
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If
> >> you
> >>>>>>>>> completely squash history, you lose a tremendous amount of
> context,
> >>>>>> which I
> >>>>>>>>> use extensively to figure out why a bug is the way it is. Only
> >> knowing
> >>>>>> that
> >>>>>>>>> the branch was merged at a given point in time doesn't give any
> >>>>>> context.
> >>>>>>>>> Seeing the individual commit history of the branch helps to
> >> preserve
> >>>>>> the
> >>>>>>>>> rationale for why the code was written the way it was. In theory
> if
> >>>>>> every
> >>>>>>>>> change starts out as a branch (feature, hotfix, release), then
> why
> >> not
> >>>>>> just
> >>>>>>>>> merge the branch once it is in a good and acceptable state?
> >>>>>>>>>
> >>>>>>>>> I also agree with Mike that this will have to be a transition
> over
> >>>>>> time. It
> >>>>>>>>> will take some time to clean up master to the point where it can
> be
> >>>>>>>>> considered a solid stable branch. Possibly as part of the 4.5
> >> release.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
> >> runseb@gmail.com
> >>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <
> >> daan.hoogland@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Sebastien,
> >>>>>>>>>>>
> >>>>>>>>>>> It seems we can do what you are calling for is creating a
> branch
> >>>>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
> >>>>>> master,
> >>>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
> >> in a
> >>>>>>>>>>> branch make a fork of that branch and when that fork is working
> >> do a
> >>>>>>>>>>> cherry-pick. The -forward concept is now used for that but it
> is
> >>>>>>>>>>> broken because more then for one piece of work there are
> commits
> >> on
> >>>>>>>>>>> it. This caused me conflicts during the release. Especially
> >> painfull
> >>>>>>>>>>> as not all was intended to get into the release. We can create
> >> this
> >>>>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
> >>>>>> changes.
> >>>>>>>>>>
> >>>>>>>>>> Yes, that's what I am thinking about too, so +1
> >>>>>>>>>>
> >>>>>>>>>> Our master would become the -develop- in gitflow terms
> >>>>>>>>>> The release branch you mention would become the -master- in
> >> gitflow
> >>>>>> terms
> >>>>>>>>>>
> >>>>>>>>>> If we start now, indeed we can create 'release' from 4.4 release
> >> tag
> >>>>>>>>>> (voted and shipped).
> >>>>>>>>>>
> >>>>>>>>>> That means that to create 4.5 we will need to merge features
> back
> >> into
> >>>>>>>>>> 'release'. it might be messy because some of those features are
> >>>>>> already in
> >>>>>>>>>> our current master.
> >>>>>>>>>>
> >>>>>>>>>> But all of this will keep 'release' clean (we can keep track of
> >> bugs
> >>>>>> and
> >>>>>>>>>> features that are in it in CHANGES file etc..)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> There is a question of control. Do we allow all committers to
> >> manage
> >>>>>>>>>>> the release? I am for that but can imagine not everybody is.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> At first I would say that only the RM can commit to 'release'.
> As
> >> we
> >>>>>> get
> >>>>>>>>>> the CI in place  we could relax this and allow commits that pass
> >> the
> >>>>>> CI to
> >>>>>>>>>> get into 'release', but right now I would vote for a tighter
> >> control
> >>>>>> of
> >>>>>>>>>> 'release'.
> >>>>>>>>>>
> >>>>>>>>>>> rule number 1 will be: you are going to do something to the
> >> code, you
> >>>>>>>>>>> start by creating a branch.
> >>>>>>>>>>>
> >>>>>>>>>>> right?
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
> >>>>>> runseb@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <
> >> sam.schmit@appcore.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hey everyone,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I've been a developer for a handful of years and have had my
> >> share
> >>>>>> of
> >>>>>>>>>>>>> experience with different version control systems.  I've used
> >> (for
> >>>>>>>>>> better
> >>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Each of these solutions offers their own unique set of
> >> features,
> >>>>>>>>>> strengths
> >>>>>>>>>>>>> and weaknesses.  As there are so many systems that are good
> at
> >>>>>> specific
> >>>>>>>>>>>>> things, it seems best to use the features that the chosen
> >> system is
> >>>>>>>>>> best at.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Git is great at branching, merging and using that structure
> to
> >>>>>>>>>> maintain and
> >>>>>>>>>>>>> control how changes get into the primary branches.  Git tools
> >> even
> >>>>>> make
> >>>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
> >>>>>> branching
> >>>>>>>>>> and
> >>>>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to
> >> NOT
> >>>>>> make
> >>>>>>>>>> use
> >>>>>>>>>>>>> of these built-in capabilities.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In addition to that, I know that the current method of change
> >>>>>>>>>> management is
> >>>>>>>>>>>>> incredibly frustrating to work with, and works directly
> >> against the
> >>>>>>>>>> way a
> >>>>>>>>>>>>> typical Git user would expect it to be structured.  I should
> >> NEVER
> >>>>>> have
> >>>>>>>>>>>>> problem compiling and running something on master.  I should
> >> not
> >>>>>> have
> >>>>>>>>>>>>> problems building anything on a release branch.  A
> >> feature/bugfix
> >>>>>>>>>> branch is
> >>>>>>>>>>>>> where things can be, and often are, broken or unstable.
>  There
> >> have
> >>>>>>>>>> been
> >>>>>>>>>>>>> many times working in Cloudstack where I've had to search
> for a
> >>>>>> stable
> >>>>>>>>>>>>> revision on master, and that's just plain wrong.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I do realize that having this many developers working on so
> >> many
> >>>>>>>>>> features
> >>>>>>>>>>>>> and bugfixes will result in a large number of branches.  I
> >> don't
> >>>>>>>>>> believe
> >>>>>>>>>>>>> this is a good argument against using a branching method,
> >> though -
> >>>>>> I
> >>>>>>>>>>>>> believe that the current system is even more confusing and
> >>>>>> difficult
> >>>>>>>>>> to use.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I could pontificate on change management quite a bit more,
> but
> >> my
> >>>>>>>>>> opinion
> >>>>>>>>>>>>> in summary would basically be:  use Git the way it was meant
> >> to be
> >>>>>>>>>> used,
> >>>>>>>>>>>>> and things will be better.  Just my two cents.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Sam
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Sam, I think we are in agreement (at least with folks who
> >> responded
> >>>>>> to
> >>>>>>>>>> this thread).
> >>>>>>>>>>>> Or maybe I am not reading your mail right and you don't agree
> >> with
> >>>>>> Leo ?
> >>>>>>>>>>>>
> >>>>>>>>>>>> My own take and reason for calling for a change we are
> currently
> >>>>>> doing
> >>>>>>>>>> things is mostly due to the way we release.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would like to see a stable master (and I think we are in
> >> agreement
> >>>>>>>>>> with that).
> >>>>>>>>>>>> That means that development should not happen on master and
> that
> >>>>>> every
> >>>>>>>>>> commit that lands on master should be shippable.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I personally have no issues with cherry-picking. So I would be
> >> fine
> >>>>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
> >>>>>>>>>>>> The end result is that the next commit on master would still
> >> mean
> >>>>>>>>>> master is shippable/releasable.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If we agree with this basic concept. The question becomes how
> >> do we
> >>>>>> get
> >>>>>>>>>> there, considering that master is now full of dev work and
> >> potential
> >>>>>> bug.
> >>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
> >> previous
> >>>>>>>>>> release branches.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our
> >> way
> >>>>>> back,
> >>>>>>>>>> merging the new features that are already in master into the new
> >>>>>> master
> >>>>>>>>>> (based on 4.4).
> >>>>>>>>>>>> This could be quite complicated but we need to do it (or
> >> something
> >>>>>> like
> >>>>>>>>>> it).
> >>>>>>>>>>>>
> >>>>>>>>>>>> To move forward, we should make a proposal to the list and
> call
> >> for
> >>>>>> a
> >>>>>>>>>> vote.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Any takers to start a wiki page proposing a new git process
> and
> >> how
> >>>>>> we
> >>>>>>>>>> could move to it (transition path) ?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> -Sebastien
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
> >>>>>>>>>> LSimons@schubergphilis.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hey folks,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
> >> implement
> >>>>>> this?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
> >>>>>>>>>> committer so
> >>>>>>>>>>>>>> its not that practical for me to volunteer!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> which might be easier to read.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Similarly, the git-flow scripts that help out with
> >> implementing
> >>>>>> this
> >>>>>>>>>> stuff
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> https://github.com/nvie/gitflow
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> they also describe the relationship between gitflow and
> >> dealing
> >>>>>> with
> >>>>>>>>>>>>>> multiple remotes
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
> >> support
> >>>>>> for
> >>>>>>>>>>>>>> git-flow
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> http://www.sourcetreeapp.com/
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Because cloudstack currently is full of rebasing and
> >> squashing and
> >>>>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
> >>>>>> visualization
> >>>>>>>>>> tool
> >>>>>>>>>>>>>> (like this or gitk or ...) right now, but it would be
> *great*
> >> to
> >>>>>> have
> >>>>>>>>>> going
> >>>>>>>>>>>>>> forward.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> cheers,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Leo
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
> >> runseb@gmail.com
> >>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I would like to re-start this discussion.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thinking about our release procedure, we clearly need more
> >> tests
> >>>>>> and
> >>>>>>>>>> a
> >>>>>>>>>>>>>> CI. However it looks like this is going to take some time.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
> >>>>>> agreeing
> >>>>>>>>>> to
> >>>>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just
> >> need to
> >>>>>>>>>> agree on
> >>>>>>>>>>>>>> the git workflow.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Right now Master is really a development branch, we should
> >> make
> >>>>>> it a
> >>>>>>>>>>>>>> stable branch for production with very few commits.
> >>>>>>>>>>>>>>> This does not mean that we would release less, in contrary
> >> this
> >>>>>> would
> >>>>>>>>>>>>>> ensure that a commit to master means it's a production
> >> release.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back
> >> to
> >>>>>>>>>> Rajani's
> >>>>>>>>>>>>>> point) everything is based on merges.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I am of the opinion that git flow provides a nice process.
> It
> >>>>>>>>>> basically
> >>>>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
> >>>>>> releases
> >>>>>>>>>>>>>> branches are branched off of that and merged into master and
> >> back
> >>>>>> into
> >>>>>>>>>>>>>> develop….etc
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Please read [1] it's a good read.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> And let's discuss,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [1]
> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Sebastien
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
> >>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> There is also the problem of cherry-picking.
> >>>>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches
> >> for
> >>>>>> each
> >>>>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches.
> >> which
> >>>>>> means
> >>>>>>>>>>>>>> distinct commits for each branch and I don’t easily know
> >> which all
> >>>>>>>>>> branches
> >>>>>>>>>>>>>> my commit exists unless I do grep.
> >>>>>>>>>>>>>>>> if we follow merging strategy properly, apart from the
> first
> >>>>>> merge
> >>>>>>>>>> of
> >>>>>>>>>>>>>> the branch, everything else on top of it should be a
> painless
> >>>>>> merge.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
> >>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I think many of the bullet points are what we are
> currently
> >>>>>> doing
> >>>>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to
> >> stay
> >>>>>> in
> >>>>>>>>>> sync
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>> master, no back-merging). I also think that much of what
> >> we do
> >>>>>> now
> >>>>>>>>>> is
> >>>>>>>>>>>>>> done
> >>>>>>>>>>>>>>>>> the way it is simply because there *are* vast changes
> >> between
> >>>>>>>>>> versions.
> >>>>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the
> >> time.
> >>>>>> If
> >>>>>>>>>> its
> >>>>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine,
> but
> >> some
> >>>>>>>>>> quick
> >>>>>>>>>>>>>> tests
> >>>>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with
> >> having
> >>>>>> single
> >>>>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits
> >> where
> >>>>>> each
> >>>>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to
> remember
> >>>>>> why we
> >>>>>>>>>> went
> >>>>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
> >>>>>> somewhere, but
> >>>>>>>>>>>>>> one of
> >>>>>>>>>>>>>>>>> the nice things it provides is the ability for the
> release
> >>>>>> manager
> >>>>>>>>>> to
> >>>>>>>>>>>>>>>>> control what changes are made during code freeze while
> >> giving
> >>>>>>>>>> people a
> >>>>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not
> always
> >>>>>>>>>> followed).
> >>>>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have
> >> their
> >>>>>> own
> >>>>>>>>>>>>>> repo and
> >>>>>>>>>>>>>>>>> issue pull requests for bugfixes?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> >>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
> >>>>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> >>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a
> empty
> >>>>>>>>>>>>>> merge(merge -s
> >>>>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
> >>>>>> bring in
> >>>>>>>>>> any
> >>>>>>>>>>>>>>>>>> changes.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a
> major
> >>>>>>>>>> rewrite, we
> >>>>>>>>>>>>>>>>>> could stop merging to that branch and above and make the
> >> fix
> >>>>>>>>>> manually.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>>>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a
> >> particular fix
> >>>>>>>>>> for an
> >>>>>>>>>>>>>> old
> >>>>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does
> >> happen.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to
> branch
> >> x"
> >>>>>> in
> >>>>>>>>>> SVN
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
> >>>>>> branch(es).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>>>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
> >> versions, or
> >>>>>>>>>> has to
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
> >> changed?
> >>>>>>>>>> Don't
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after
> >> that?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>> Stephen Turner
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
> >> mike.tutkowski@solidfire.com]
> >>>>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
> >>>>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
> >>>>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
> >>>>>> consider.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be
> error
> >>>>>> prone
> >>>>>>>>>> in
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
> >> applicable
> >>>>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks
> are
> >>>>>>>>>> related.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to
> >> see
> >>>>>> if you
> >>>>>>>>>>>>>>>>>> checked a
> >>>>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In
> >> such a
> >>>>>>>>>>>>>> situation,
> >>>>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
> >> check-in
> >>>>>>>>>> was no
> >>>>>>>>>>>>>>>>>> longer
> >>>>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to
> >> mark
> >>>>>> it as
> >>>>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure
> >> about
> >>>>>> Git).
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the
> >> *forward
> >>>>>>>>>> branches
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all
> >> releases the
> >>>>>>>>>> commit
> >>>>>>>>>>>>>> has
> >>>>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also,
> as a
> >>>>>>>>>>>>>> contributor, I
> >>>>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
> >>>>>> cleanly
> >>>>>>>>>>>>>> apply on
> >>>>>>>>>>>>>>>>>>>>>> different branches.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is
> what I
> >>>>>>>>>> propose.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major
> release(ex:
> >>>>>> 4.3.x,
> >>>>>>>>>>>>>> 4.4.x,
> >>>>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
> >>>>>>>>>> accordingly
> >>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>> the respective branches.
> >>>>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed.
> >> Many
> >>>>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when
> we
> >>>>>>>>>> cherry-pick,
> >>>>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
> >>>>>> change or
> >>>>>>>>>>>>>> fix and
> >>>>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
> >> release
> >>>>>>>>>> branches
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They
> should
> >> be
> >>>>>>>>>>>>>> merged(either
> >>>>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
> >>>>>> trackable
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>> git branch --contains
> >>>>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
> >> release
> >>>>>>>>>> uptill
> >>>>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches
> master.
> >>>>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> >>>>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next
> time
> >> a
> >>>>>> new
> >>>>>>>>>> commit
> >>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>> done this will also get merged.
> >>>>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
> >> master
> >>>>>> to
> >>>>>>>>>>>>>> feature
> >>>>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
> >>>>>> proactively
> >>>>>>>>>>>>>> take
> >>>>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
> >> master
> >>>>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
> >> master on
> >>>>>>>>>> code
> >>>>>>>>>>>>>>>>>>>>>> complete through a merge.
> >>>>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
> >> release
> >>>>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any
> minor
> >>>>>> release)
> >>>>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
> >> information
> >>>>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>;
> reviewed
> >> by
> >>>>>>>>>>>>>>>>>> <committer>
> >>>>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
> >>>>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
> >> freeze),
> >>>>>>>>>> any bug
> >>>>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
> >>>>>> release(4.4)
> >>>>>>>>>> only
> >>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
> >> branch.
> >>>>>>>>>> This
> >>>>>>>>>>>>>> can be
> >>>>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be
> using
> >>>>>> jira
> >>>>>>>>>> vote?)
> >>>>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another
> >> branch
> >>>>>>>>>>>>>>>>>> maintenance.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Ref:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> ~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
> >>> *™*
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>> *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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> *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.
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> 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>*™*
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> 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: [DISCUSS][PROPOSAL] git workflow

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

On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <mi...@solidfire.com> wrote:

> I believe I agree with these steps.
> 
> A couple questions:
> 
> Is 'master' simply always going to be equal to what's the most recent
> version of the code that's in production?

I think so. master will always be at the latest release and all the previous releases properly tagged. The release branches would be deleted once release is done.

> 
> Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
> into RELEASE-4.5?
> 

Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes should be done on the 4.5 branch.



~Rajani


> 
> On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
> Rajani.Karuturi@citrix.com> wrote:
> 
>> 
>> Hi Daan,
>> here is what i propose:
>> 
>> 1. rename 'master' to 'develop’
>> 2. branch a new 'master' from '4.4’
>> 3. branch 'RELEASE-4.5' from the develop
>> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>> 
>> RELEASE-4.6 branch should be off develop as all the feature branches would
>> be merged there before freeze for 4.6 and would be merged to master when
>> the release is voted.
>> 
>> The other question I have is in the step:4. how are we going to manage
>> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is done)
>> 
>> ~Rajani
>> 
>> 
>> 
>> On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com>
>> wrote:
>> 
>>> Mike, Rajani,
>>> 
>>> Sebastien's point was that the current 4.4 is the closest we have to a
>>> releasable branch. I don't mind enting on master but it will require
>>> more fixing. In general all of this will require some RM work of all
>>> committers. Please ammend my little proposal if you will.
>>> 
>>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
>>> <Ra...@citrix.com> wrote:
>>>> I agree with mike. I think we should start 4.5 from where master is now
>>>> Also create a develop branch from master and continue future work for
>> 4.6 there.
>>>> 
>>>> I am not clear on how the release branches are going to be maintained.
>>>> Are we saying we would create 4.5-RELEASE branch which is essentially
>> same as our current -FORWARD branch and continue cherry-picking?
>>>> 
>>>> I would prefer merges to cherry-picks.
>>>> Also, I think we should allow committers to commit to the RELEASE
>> branch after discussing about it on dev@ and have RM closely monitor them.
>>>> Any commit intended for 4.5 RELEASE should be checked in after
>> discussion in the 4.5 Release branch and then merged to develop branch.
>>>> 
>>>> 
>>>> ~Rajani
>>>> 
>>>> 
>>>> 
>>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>>>> 
>>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4 left
>> off
>>>>> and then merge features from develop into 4.5.
>>>>> 
>>>>> Why don't we instead start 4.5 where master is now with the assumption
>> that
>>>>> since we are past Feature Freeze for 4.5 that master is stable enough?
>>>>> 
>>>>> 
>>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
>> daan.hoogland@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> so to start formulate a proposal:
>>>>>> 
>>>>>> all work shall be done in a new branch (it is advisable to prefix your
>>>>>> branches with your id)
>>>>>> when working, features will be cherry-picked/merged into the release
>>>>>> branch they are for and next into master.
>>>>>> hotfixes will be done in <branchname>-hotfixes
>>>>>> 
>>>>>> as transition we will
>>>>>> 
>>>>>> rename 'master' to 'develop'
>>>>>> branch a new 'master' from '4.4'
>>>>>> branch '4.5' from the new 'master'
>>>>>> merge any features from the new 'develop' to '4.5' and 'master'
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <runseb@gmail.com
>>> 
>>>>>> wrote:
>>>>>>> 
>>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <ru...@gmail.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Let me ask the question, why have master be develop and a release
>>>>>> branch be
>>>>>>>>> "master"? If we are going to follow gitflow, why not just stick
>> with
>>>>>> the
>>>>>>>>> norm? If master is the development branch, it might not be stable.
>> I
>>>>>> think
>>>>>>>>> the goal here is that we have an obvious stable branch. Anyone
>> could
>>>>>> come
>>>>>>>>> check out master and have the latest useable.
>>>>>>>> 
>>>>>>>> I am in favor of following the norm, so ideally master should be our
>>>>>> stable branch (agreed).
>>>>>>>> 
>>>>>>>> The issue is with the transition.
>>>>>>>> 
>>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
>> ideally
>>>>>> we could start a stable branch of this tag and build up bug fix
>> releases
>>>>>> all the way to 4.5 from there.
>>>>>>>> 
>>>>>>>> But all features for 4.5 are already in master.
>>>>>>>> 
>>>>>>>> So if we create a 'develop' branch of master and stabilize 'master'
>>>>>> then develop is now started from a stable tag (4.4.0).
>>>>>>>> 
>>>>>>> 
>>>>>>> *not* started from a stable tag, and merges will be tricky, no ?
>>>>>>> 
>>>>>>>> So what's the best way to flip ? There is most likely some git magic
>>>>>> that can we do.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> The new git workflow and the transition process need to be part of a
>>>>>> proposal that we get consensus on.
>>>>>>>> 
>>>>>>>> getting there :)
>>>>>>>> 
>>>>>>>> -seb
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If
>> you
>>>>>>>>> completely squash history, you lose a tremendous amount of context,
>>>>>> which I
>>>>>>>>> use extensively to figure out why a bug is the way it is. Only
>> knowing
>>>>>> that
>>>>>>>>> the branch was merged at a given point in time doesn't give any
>>>>>> context.
>>>>>>>>> Seeing the individual commit history of the branch helps to
>> preserve
>>>>>> the
>>>>>>>>> rationale for why the code was written the way it was. In theory if
>>>>>> every
>>>>>>>>> change starts out as a branch (feature, hotfix, release), then why
>> not
>>>>>> just
>>>>>>>>> merge the branch once it is in a good and acceptable state?
>>>>>>>>> 
>>>>>>>>> I also agree with Mike that this will have to be a transition over
>>>>>> time. It
>>>>>>>>> will take some time to clean up master to the point where it can be
>>>>>>>>> considered a solid stable branch. Possibly as part of the 4.5
>> release.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
>> runseb@gmail.com
>>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <
>> daan.hoogland@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Sebastien,
>>>>>>>>>>> 
>>>>>>>>>>> It seems we can do what you are calling for is creating a branch
>>>>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
>>>>>> master,
>>>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
>> in a
>>>>>>>>>>> branch make a fork of that branch and when that fork is working
>> do a
>>>>>>>>>>> cherry-pick. The -forward concept is now used for that but it is
>>>>>>>>>>> broken because more then for one piece of work there are commits
>> on
>>>>>>>>>>> it. This caused me conflicts during the release. Especially
>> painfull
>>>>>>>>>>> as not all was intended to get into the release. We can create
>> this
>>>>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
>>>>>> changes.
>>>>>>>>>> 
>>>>>>>>>> Yes, that's what I am thinking about too, so +1
>>>>>>>>>> 
>>>>>>>>>> Our master would become the -develop- in gitflow terms
>>>>>>>>>> The release branch you mention would become the -master- in
>> gitflow
>>>>>> terms
>>>>>>>>>> 
>>>>>>>>>> If we start now, indeed we can create 'release' from 4.4 release
>> tag
>>>>>>>>>> (voted and shipped).
>>>>>>>>>> 
>>>>>>>>>> That means that to create 4.5 we will need to merge features back
>> into
>>>>>>>>>> 'release'. it might be messy because some of those features are
>>>>>> already in
>>>>>>>>>> our current master.
>>>>>>>>>> 
>>>>>>>>>> But all of this will keep 'release' clean (we can keep track of
>> bugs
>>>>>> and
>>>>>>>>>> features that are in it in CHANGES file etc..)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> There is a question of control. Do we allow all committers to
>> manage
>>>>>>>>>>> the release? I am for that but can imagine not everybody is.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> At first I would say that only the RM can commit to 'release'. As
>> we
>>>>>> get
>>>>>>>>>> the CI in place  we could relax this and allow commits that pass
>> the
>>>>>> CI to
>>>>>>>>>> get into 'release', but right now I would vote for a tighter
>> control
>>>>>> of
>>>>>>>>>> 'release'.
>>>>>>>>>> 
>>>>>>>>>>> rule number 1 will be: you are going to do something to the
>> code, you
>>>>>>>>>>> start by creating a branch.
>>>>>>>>>>> 
>>>>>>>>>>> right?
>>>>>>>>>>> 
>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
>>>>>> runseb@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <
>> sam.schmit@appcore.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I've been a developer for a handful of years and have had my
>> share
>>>>>> of
>>>>>>>>>>>>> experience with different version control systems.  I've used
>> (for
>>>>>>>>>> better
>>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Each of these solutions offers their own unique set of
>> features,
>>>>>>>>>> strengths
>>>>>>>>>>>>> and weaknesses.  As there are so many systems that are good at
>>>>>> specific
>>>>>>>>>>>>> things, it seems best to use the features that the chosen
>> system is
>>>>>>>>>> best at.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Git is great at branching, merging and using that structure to
>>>>>>>>>> maintain and
>>>>>>>>>>>>> control how changes get into the primary branches.  Git tools
>> even
>>>>>> make
>>>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
>>>>>> branching
>>>>>>>>>> and
>>>>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to
>> NOT
>>>>>> make
>>>>>>>>>> use
>>>>>>>>>>>>> of these built-in capabilities.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In addition to that, I know that the current method of change
>>>>>>>>>> management is
>>>>>>>>>>>>> incredibly frustrating to work with, and works directly
>> against the
>>>>>>>>>> way a
>>>>>>>>>>>>> typical Git user would expect it to be structured.  I should
>> NEVER
>>>>>> have
>>>>>>>>>>>>> problem compiling and running something on master.  I should
>> not
>>>>>> have
>>>>>>>>>>>>> problems building anything on a release branch.  A
>> feature/bugfix
>>>>>>>>>> branch is
>>>>>>>>>>>>> where things can be, and often are, broken or unstable.  There
>> have
>>>>>>>>>> been
>>>>>>>>>>>>> many times working in Cloudstack where I've had to search for a
>>>>>> stable
>>>>>>>>>>>>> revision on master, and that's just plain wrong.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I do realize that having this many developers working on so
>> many
>>>>>>>>>> features
>>>>>>>>>>>>> and bugfixes will result in a large number of branches.  I
>> don't
>>>>>>>>>> believe
>>>>>>>>>>>>> this is a good argument against using a branching method,
>> though -
>>>>>> I
>>>>>>>>>>>>> believe that the current system is even more confusing and
>>>>>> difficult
>>>>>>>>>> to use.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I could pontificate on change management quite a bit more, but
>> my
>>>>>>>>>> opinion
>>>>>>>>>>>>> in summary would basically be:  use Git the way it was meant
>> to be
>>>>>>>>>> used,
>>>>>>>>>>>>> and things will be better.  Just my two cents.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Sam
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Sam, I think we are in agreement (at least with folks who
>> responded
>>>>>> to
>>>>>>>>>> this thread).
>>>>>>>>>>>> Or maybe I am not reading your mail right and you don't agree
>> with
>>>>>> Leo ?
>>>>>>>>>>>> 
>>>>>>>>>>>> My own take and reason for calling for a change we are currently
>>>>>> doing
>>>>>>>>>> things is mostly due to the way we release.
>>>>>>>>>>>> 
>>>>>>>>>>>> I would like to see a stable master (and I think we are in
>> agreement
>>>>>>>>>> with that).
>>>>>>>>>>>> That means that development should not happen on master and that
>>>>>> every
>>>>>>>>>> commit that lands on master should be shippable.
>>>>>>>>>>>> 
>>>>>>>>>>>> I personally have no issues with cherry-picking. So I would be
>> fine
>>>>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
>>>>>>>>>>>> The end result is that the next commit on master would still
>> mean
>>>>>>>>>> master is shippable/releasable.
>>>>>>>>>>>> 
>>>>>>>>>>>> If we agree with this basic concept. The question becomes how
>> do we
>>>>>> get
>>>>>>>>>> there, considering that master is now full of dev work and
>> potential
>>>>>> bug.
>>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
>> previous
>>>>>>>>>> release branches.
>>>>>>>>>>>> 
>>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our
>> way
>>>>>> back,
>>>>>>>>>> merging the new features that are already in master into the new
>>>>>> master
>>>>>>>>>> (based on 4.4).
>>>>>>>>>>>> This could be quite complicated but we need to do it (or
>> something
>>>>>> like
>>>>>>>>>> it).
>>>>>>>>>>>> 
>>>>>>>>>>>> To move forward, we should make a proposal to the list and call
>> for
>>>>>> a
>>>>>>>>>> vote.
>>>>>>>>>>>> 
>>>>>>>>>>>> Any takers to start a wiki page proposing a new git process and
>> how
>>>>>> we
>>>>>>>>>> could move to it (transition path) ?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> -Sebastien
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>>>>>>>>>> LSimons@schubergphilis.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hey folks,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
>> implement
>>>>>> this?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
>>>>>>>>>> committer so
>>>>>>>>>>>>>> its not that practical for me to volunteer!
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> which might be easier to read.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Similarly, the git-flow scripts that help out with
>> implementing
>>>>>> this
>>>>>>>>>> stuff
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> https://github.com/nvie/gitflow
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> they also describe the relationship between gitflow and
>> dealing
>>>>>> with
>>>>>>>>>>>>>> multiple remotes
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
>> support
>>>>>> for
>>>>>>>>>>>>>> git-flow
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> http://www.sourcetreeapp.com/
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Because cloudstack currently is full of rebasing and
>> squashing and
>>>>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
>>>>>> visualization
>>>>>>>>>> tool
>>>>>>>>>>>>>> (like this or gitk or ...) right now, but it would be *great*
>> to
>>>>>> have
>>>>>>>>>> going
>>>>>>>>>>>>>> forward.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> cheers,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Leo
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
>> runseb@gmail.com
>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I would like to re-start this discussion.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thinking about our release procedure, we clearly need more
>> tests
>>>>>> and
>>>>>>>>>> a
>>>>>>>>>>>>>> CI. However it looks like this is going to take some time.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
>>>>>> agreeing
>>>>>>>>>> to
>>>>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just
>> need to
>>>>>>>>>> agree on
>>>>>>>>>>>>>> the git workflow.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Right now Master is really a development branch, we should
>> make
>>>>>> it a
>>>>>>>>>>>>>> stable branch for production with very few commits.
>>>>>>>>>>>>>>> This does not mean that we would release less, in contrary
>> this
>>>>>> would
>>>>>>>>>>>>>> ensure that a commit to master means it's a production
>> release.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back
>> to
>>>>>>>>>> Rajani's
>>>>>>>>>>>>>> point) everything is based on merges.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I am of the opinion that git flow provides a nice process. It
>>>>>>>>>> basically
>>>>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
>>>>>> releases
>>>>>>>>>>>>>> branches are branched off of that and merged into master and
>> back
>>>>>> into
>>>>>>>>>>>>>> develop….etc
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Please read [1] it's a good read.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> And let's discuss,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> -Sebastien
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> There is also the problem of cherry-picking.
>>>>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches
>> for
>>>>>> each
>>>>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches.
>> which
>>>>>> means
>>>>>>>>>>>>>> distinct commits for each branch and I don’t easily know
>> which all
>>>>>>>>>> branches
>>>>>>>>>>>>>> my commit exists unless I do grep.
>>>>>>>>>>>>>>>> if we follow merging strategy properly, apart from the first
>>>>>> merge
>>>>>>>>>> of
>>>>>>>>>>>>>> the branch, everything else on top of it should be a painless
>>>>>> merge.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I think many of the bullet points are what we are currently
>>>>>> doing
>>>>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to
>> stay
>>>>>> in
>>>>>>>>>> sync
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> master, no back-merging). I also think that much of what
>> we do
>>>>>> now
>>>>>>>>>> is
>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>>>> the way it is simply because there *are* vast changes
>> between
>>>>>>>>>> versions.
>>>>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the
>> time.
>>>>>> If
>>>>>>>>>> its
>>>>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine, but
>> some
>>>>>>>>>> quick
>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with
>> having
>>>>>> single
>>>>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits
>> where
>>>>>> each
>>>>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember
>>>>>> why we
>>>>>>>>>> went
>>>>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
>>>>>> somewhere, but
>>>>>>>>>>>>>> one of
>>>>>>>>>>>>>>>>> the nice things it provides is the ability for the release
>>>>>> manager
>>>>>>>>>> to
>>>>>>>>>>>>>>>>> control what changes are made during code freeze while
>> giving
>>>>>>>>>> people a
>>>>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not always
>>>>>>>>>> followed).
>>>>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have
>> their
>>>>>> own
>>>>>>>>>>>>>> repo and
>>>>>>>>>>>>>>>>> issue pull requests for bugfixes?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
>>>>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>>>>>>>>>>>>>> merge(merge -s
>>>>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
>>>>>> bring in
>>>>>>>>>> any
>>>>>>>>>>>>>>>>>> changes.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a major
>>>>>>>>>> rewrite, we
>>>>>>>>>>>>>>>>>> could stop merging to that branch and above and make the
>> fix
>>>>>>>>>> manually.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a
>> particular fix
>>>>>>>>>> for an
>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does
>> happen.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to branch
>> x"
>>>>>> in
>>>>>>>>>> SVN
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
>>>>>> branch(es).
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
>> versions, or
>>>>>>>>>> has to
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
>> changed?
>>>>>>>>>> Don't
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after
>> that?
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Stephen Turner
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
>> mike.tutkowski@solidfire.com]
>>>>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
>>>>>> consider.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be error
>>>>>> prone
>>>>>>>>>> in
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
>> applicable
>>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
>>>>>>>>>> related.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to
>> see
>>>>>> if you
>>>>>>>>>>>>>>>>>> checked a
>>>>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In
>> such a
>>>>>>>>>>>>>> situation,
>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
>> check-in
>>>>>>>>>> was no
>>>>>>>>>>>>>>>>>> longer
>>>>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to
>> mark
>>>>>> it as
>>>>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure
>> about
>>>>>> Git).
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the
>> *forward
>>>>>>>>>> branches
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all
>> releases the
>>>>>>>>>> commit
>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>>>>>>>>>>>>>> contributor, I
>>>>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
>>>>>> cleanly
>>>>>>>>>>>>>> apply on
>>>>>>>>>>>>>>>>>>>>>> different branches.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
>>>>>>>>>> propose.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major release(ex:
>>>>>> 4.3.x,
>>>>>>>>>>>>>> 4.4.x,
>>>>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>>>>>>>>>> accordingly
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>> the respective branches.
>>>>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed.
>> Many
>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
>>>>>>>>>> cherry-pick,
>>>>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
>>>>>> change or
>>>>>>>>>>>>>> fix and
>>>>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
>> release
>>>>>>>>>> branches
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should
>> be
>>>>>>>>>>>>>> merged(either
>>>>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
>>>>>> trackable
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>> git branch --contains
>>>>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
>> release
>>>>>>>>>> uptill
>>>>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time
>> a
>>>>>> new
>>>>>>>>>> commit
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
>> master
>>>>>> to
>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
>>>>>> proactively
>>>>>>>>>>>>>> take
>>>>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
>> master
>>>>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
>> master on
>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>> complete through a merge.
>>>>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
>> release
>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor
>>>>>> release)
>>>>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
>> information
>>>>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed
>> by
>>>>>>>>>>>>>>>>>> <committer>
>>>>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
>> freeze),
>>>>>>>>>> any bug
>>>>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
>>>>>> release(4.4)
>>>>>>>>>> only
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
>> branch.
>>>>>>>>>> This
>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be using
>>>>>> jira
>>>>>>>>>> vote?)
>>>>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another
>> branch
>>>>>>>>>>>>>>>>>> maintenance.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Ref:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> ~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
>>> *™*
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> *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
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> *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.
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> 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>*™*
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> 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: [DISCUSS][PROPOSAL] git workflow

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

I believe I agree with these steps.

A couple questions:

Is 'master' simply always going to be equal to what's the most recent
version of the code that's in production?

Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
into RELEASE-4.5?


On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
Rajani.Karuturi@citrix.com> wrote:

>
> Hi Daan,
> here is what i propose:
>
> 1. rename 'master' to 'develop’
> 2. branch a new 'master' from '4.4’
> 3. branch 'RELEASE-4.5' from the develop
> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>
> RELEASE-4.6 branch should be off develop as all the feature branches would
> be merged there before freeze for 4.6 and would be merged to master when
> the release is voted.
>
> The other question I have is in the step:4. how are we going to manage
> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is done)
>
> ~Rajani
>
>
>
> On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com>
> wrote:
>
> > Mike, Rajani,
> >
> > Sebastien's point was that the current 4.4 is the closest we have to a
> > releasable branch. I don't mind enting on master but it will require
> > more fixing. In general all of this will require some RM work of all
> > committers. Please ammend my little proposal if you will.
> >
> > On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
> > <Ra...@citrix.com> wrote:
> >> I agree with mike. I think we should start 4.5 from where master is now
> >> Also create a develop branch from master and continue future work for
> 4.6 there.
> >>
> >> I am not clear on how the release branches are going to be maintained.
> >> Are we saying we would create 4.5-RELEASE branch which is essentially
> same as our current -FORWARD branch and continue cherry-picking?
> >>
> >> I would prefer merges to cherry-picks.
> >> Also, I think we should allow committers to commit to the RELEASE
> branch after discussing about it on dev@ and have RM closely monitor them.
> >> Any commit intended for 4.5 RELEASE should be checked in after
> discussion in the 4.5 Release branch and then merged to develop branch.
> >>
> >>
> >> ~Rajani
> >>
> >>
> >>
> >> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
> >>
> >>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4 left
> off
> >>> and then merge features from develop into 4.5.
> >>>
> >>> Why don't we instead start 4.5 where master is now with the assumption
> that
> >>> since we are past Feature Freeze for 4.5 that master is stable enough?
> >>>
> >>>
> >>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
> daan.hoogland@gmail.com>
> >>> wrote:
> >>>
> >>>> so to start formulate a proposal:
> >>>>
> >>>> all work shall be done in a new branch (it is advisable to prefix your
> >>>> branches with your id)
> >>>> when working, features will be cherry-picked/merged into the release
> >>>> branch they are for and next into master.
> >>>> hotfixes will be done in <branchname>-hotfixes
> >>>>
> >>>> as transition we will
> >>>>
> >>>> rename 'master' to 'develop'
> >>>> branch a new 'master' from '4.4'
> >>>> branch '4.5' from the new 'master'
> >>>> merge any features from the new 'develop' to '4.5' and 'master'
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <runseb@gmail.com
> >
> >>>> wrote:
> >>>>>
> >>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <ru...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> Let me ask the question, why have master be develop and a release
> >>>> branch be
> >>>>>>> "master"? If we are going to follow gitflow, why not just stick
> with
> >>>> the
> >>>>>>> norm? If master is the development branch, it might not be stable.
> I
> >>>> think
> >>>>>>> the goal here is that we have an obvious stable branch. Anyone
> could
> >>>> come
> >>>>>>> check out master and have the latest useable.
> >>>>>>
> >>>>>> I am in favor of following the norm, so ideally master should be our
> >>>> stable branch (agreed).
> >>>>>>
> >>>>>> The issue is with the transition.
> >>>>>>
> >>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
> ideally
> >>>> we could start a stable branch of this tag and build up bug fix
> releases
> >>>> all the way to 4.5 from there.
> >>>>>>
> >>>>>> But all features for 4.5 are already in master.
> >>>>>>
> >>>>>> So if we create a 'develop' branch of master and stabilize 'master'
> >>>> then develop is now started from a stable tag (4.4.0).
> >>>>>>
> >>>>>
> >>>>> *not* started from a stable tag, and merges will be tricky, no ?
> >>>>>
> >>>>>> So what's the best way to flip ? There is most likely some git magic
> >>>> that can we do.
> >>>>>>
> >>>>>>
> >>>>>> The new git workflow and the transition process need to be part of a
> >>>> proposal that we get consensus on.
> >>>>>>
> >>>>>> getting there :)
> >>>>>>
> >>>>>> -seb
> >>>>>>
> >>>>>>>
> >>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If
> you
> >>>>>>> completely squash history, you lose a tremendous amount of context,
> >>>> which I
> >>>>>>> use extensively to figure out why a bug is the way it is. Only
> knowing
> >>>> that
> >>>>>>> the branch was merged at a given point in time doesn't give any
> >>>> context.
> >>>>>>> Seeing the individual commit history of the branch helps to
> preserve
> >>>> the
> >>>>>>> rationale for why the code was written the way it was. In theory if
> >>>> every
> >>>>>>> change starts out as a branch (feature, hotfix, release), then why
> not
> >>>> just
> >>>>>>> merge the branch once it is in a good and acceptable state?
> >>>>>>>
> >>>>>>> I also agree with Mike that this will have to be a transition over
> >>>> time. It
> >>>>>>> will take some time to clean up master to the point where it can be
> >>>>>>> considered a solid stable branch. Possibly as part of the 4.5
> release.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
> runseb@gmail.com
> >>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <
> daan.hoogland@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Sebastien,
> >>>>>>>>>
> >>>>>>>>> It seems we can do what you are calling for is creating a branch
> >>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
> >>>> master,
> >>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
> in a
> >>>>>>>>> branch make a fork of that branch and when that fork is working
> do a
> >>>>>>>>> cherry-pick. The -forward concept is now used for that but it is
> >>>>>>>>> broken because more then for one piece of work there are commits
> on
> >>>>>>>>> it. This caused me conflicts during the release. Especially
> painfull
> >>>>>>>>> as not all was intended to get into the release. We can create
> this
> >>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
> >>>> changes.
> >>>>>>>>
> >>>>>>>> Yes, that's what I am thinking about too, so +1
> >>>>>>>>
> >>>>>>>> Our master would become the -develop- in gitflow terms
> >>>>>>>> The release branch you mention would become the -master- in
> gitflow
> >>>> terms
> >>>>>>>>
> >>>>>>>> If we start now, indeed we can create 'release' from 4.4 release
> tag
> >>>>>>>> (voted and shipped).
> >>>>>>>>
> >>>>>>>> That means that to create 4.5 we will need to merge features back
> into
> >>>>>>>> 'release'. it might be messy because some of those features are
> >>>> already in
> >>>>>>>> our current master.
> >>>>>>>>
> >>>>>>>> But all of this will keep 'release' clean (we can keep track of
> bugs
> >>>> and
> >>>>>>>> features that are in it in CHANGES file etc..)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> There is a question of control. Do we allow all committers to
> manage
> >>>>>>>>> the release? I am for that but can imagine not everybody is.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> At first I would say that only the RM can commit to 'release'. As
> we
> >>>> get
> >>>>>>>> the CI in place  we could relax this and allow commits that pass
> the
> >>>> CI to
> >>>>>>>> get into 'release', but right now I would vote for a tighter
> control
> >>>> of
> >>>>>>>> 'release'.
> >>>>>>>>
> >>>>>>>>> rule number 1 will be: you are going to do something to the
> code, you
> >>>>>>>>> start by creating a branch.
> >>>>>>>>>
> >>>>>>>>> right?
> >>>>>>>>>
> >>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
> >>>> runseb@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <
> sam.schmit@appcore.com>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hey everyone,
> >>>>>>>>>>>
> >>>>>>>>>>> I've been a developer for a handful of years and have had my
> share
> >>>> of
> >>>>>>>>>>> experience with different version control systems.  I've used
> (for
> >>>>>>>> better
> >>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>>>>>>>>>
> >>>>>>>>>>> Each of these solutions offers their own unique set of
> features,
> >>>>>>>> strengths
> >>>>>>>>>>> and weaknesses.  As there are so many systems that are good at
> >>>> specific
> >>>>>>>>>>> things, it seems best to use the features that the chosen
> system is
> >>>>>>>> best at.
> >>>>>>>>>>>
> >>>>>>>>>>> Git is great at branching, merging and using that structure to
> >>>>>>>> maintain and
> >>>>>>>>>>> control how changes get into the primary branches.  Git tools
> even
> >>>> make
> >>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
> >>>> branching
> >>>>>>>> and
> >>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to
> NOT
> >>>> make
> >>>>>>>> use
> >>>>>>>>>>> of these built-in capabilities.
> >>>>>>>>>>>
> >>>>>>>>>>> In addition to that, I know that the current method of change
> >>>>>>>> management is
> >>>>>>>>>>> incredibly frustrating to work with, and works directly
> against the
> >>>>>>>> way a
> >>>>>>>>>>> typical Git user would expect it to be structured.  I should
> NEVER
> >>>> have
> >>>>>>>>>>> problem compiling and running something on master.  I should
> not
> >>>> have
> >>>>>>>>>>> problems building anything on a release branch.  A
> feature/bugfix
> >>>>>>>> branch is
> >>>>>>>>>>> where things can be, and often are, broken or unstable.  There
> have
> >>>>>>>> been
> >>>>>>>>>>> many times working in Cloudstack where I've had to search for a
> >>>> stable
> >>>>>>>>>>> revision on master, and that's just plain wrong.
> >>>>>>>>>>>
> >>>>>>>>>>> I do realize that having this many developers working on so
> many
> >>>>>>>> features
> >>>>>>>>>>> and bugfixes will result in a large number of branches.  I
> don't
> >>>>>>>> believe
> >>>>>>>>>>> this is a good argument against using a branching method,
> though -
> >>>> I
> >>>>>>>>>>> believe that the current system is even more confusing and
> >>>> difficult
> >>>>>>>> to use.
> >>>>>>>>>>>
> >>>>>>>>>>> I could pontificate on change management quite a bit more, but
> my
> >>>>>>>> opinion
> >>>>>>>>>>> in summary would basically be:  use Git the way it was meant
> to be
> >>>>>>>> used,
> >>>>>>>>>>> and things will be better.  Just my two cents.
> >>>>>>>>>>>
> >>>>>>>>>>> Sam
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Sam, I think we are in agreement (at least with folks who
> responded
> >>>> to
> >>>>>>>> this thread).
> >>>>>>>>>> Or maybe I am not reading your mail right and you don't agree
> with
> >>>> Leo ?
> >>>>>>>>>>
> >>>>>>>>>> My own take and reason for calling for a change we are currently
> >>>> doing
> >>>>>>>> things is mostly due to the way we release.
> >>>>>>>>>>
> >>>>>>>>>> I would like to see a stable master (and I think we are in
> agreement
> >>>>>>>> with that).
> >>>>>>>>>> That means that development should not happen on master and that
> >>>> every
> >>>>>>>> commit that lands on master should be shippable.
> >>>>>>>>>>
> >>>>>>>>>> I personally have no issues with cherry-picking. So I would be
> fine
> >>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
> >>>>>>>>>> The end result is that the next commit on master would still
> mean
> >>>>>>>> master is shippable/releasable.
> >>>>>>>>>>
> >>>>>>>>>> If we agree with this basic concept. The question becomes how
> do we
> >>>> get
> >>>>>>>> there, considering that master is now full of dev work and
> potential
> >>>> bug.
> >>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
> previous
> >>>>>>>> release branches.
> >>>>>>>>>>
> >>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our
> way
> >>>> back,
> >>>>>>>> merging the new features that are already in master into the new
> >>>> master
> >>>>>>>> (based on 4.4).
> >>>>>>>>>> This could be quite complicated but we need to do it (or
> something
> >>>> like
> >>>>>>>> it).
> >>>>>>>>>>
> >>>>>>>>>> To move forward, we should make a proposal to the list and call
> for
> >>>> a
> >>>>>>>> vote.
> >>>>>>>>>>
> >>>>>>>>>> Any takers to start a wiki page proposing a new git process and
> how
> >>>> we
> >>>>>>>> could move to it (transition path) ?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> -Sebastien
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
> >>>>>>>> LSimons@schubergphilis.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hey folks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
> implement
> >>>> this?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
> >>>>>>>> committer so
> >>>>>>>>>>>> its not that practical for me to volunteer!
> >>>>>>>>>>>>
> >>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
> >>>>>>>>>>>>
> >>>>>>>>>>>> which might be easier to read.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Similarly, the git-flow scripts that help out with
> implementing
> >>>> this
> >>>>>>>> stuff
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://github.com/nvie/gitflow
> >>>>>>>>>>>>
> >>>>>>>>>>>> they also describe the relationship between gitflow and
> dealing
> >>>> with
> >>>>>>>>>>>> multiple remotes
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
> >>>>>>>>>>>>
> >>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
> support
> >>>> for
> >>>>>>>>>>>> git-flow
> >>>>>>>>>>>>
> >>>>>>>>>>>> http://www.sourcetreeapp.com/
> >>>>>>>>>>>>
> >>>>>>>>>>>> Because cloudstack currently is full of rebasing and
> squashing and
> >>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
> >>>> visualization
> >>>>>>>> tool
> >>>>>>>>>>>> (like this or gitk or ...) right now, but it would be *great*
> to
> >>>> have
> >>>>>>>> going
> >>>>>>>>>>>> forward.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> cheers,
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Leo
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
> runseb@gmail.com
> >>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I would like to re-start this discussion.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thinking about our release procedure, we clearly need more
> tests
> >>>> and
> >>>>>>>> a
> >>>>>>>>>>>> CI. However it looks like this is going to take some time.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
> >>>> agreeing
> >>>>>>>> to
> >>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just
> need to
> >>>>>>>> agree on
> >>>>>>>>>>>> the git workflow.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Right now Master is really a development branch, we should
> make
> >>>> it a
> >>>>>>>>>>>> stable branch for production with very few commits.
> >>>>>>>>>>>>> This does not mean that we would release less, in contrary
> this
> >>>> would
> >>>>>>>>>>>> ensure that a commit to master means it's a production
> release.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back
> to
> >>>>>>>> Rajani's
> >>>>>>>>>>>> point) everything is based on merges.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I am of the opinion that git flow provides a nice process. It
> >>>>>>>> basically
> >>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
> >>>> releases
> >>>>>>>>>>>> branches are branched off of that and merged into master and
> back
> >>>> into
> >>>>>>>>>>>> develop….etc
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Please read [1] it's a good read.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> And let's discuss,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Sebastien
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
> >>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> There is also the problem of cherry-picking.
> >>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches
> for
> >>>> each
> >>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches.
> which
> >>>> means
> >>>>>>>>>>>> distinct commits for each branch and I don’t easily know
> which all
> >>>>>>>> branches
> >>>>>>>>>>>> my commit exists unless I do grep.
> >>>>>>>>>>>>>> if we follow merging strategy properly, apart from the first
> >>>> merge
> >>>>>>>> of
> >>>>>>>>>>>> the branch, everything else on top of it should be a painless
> >>>> merge.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
> >>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I think many of the bullet points are what we are currently
> >>>> doing
> >>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to
> stay
> >>>> in
> >>>>>>>> sync
> >>>>>>>>>>>> with
> >>>>>>>>>>>>>>> master, no back-merging). I also think that much of what
> we do
> >>>> now
> >>>>>>>> is
> >>>>>>>>>>>> done
> >>>>>>>>>>>>>>> the way it is simply because there *are* vast changes
> between
> >>>>>>>> versions.
> >>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the
> time.
> >>>> If
> >>>>>>>> its
> >>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine, but
> some
> >>>>>>>> quick
> >>>>>>>>>>>> tests
> >>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with
> having
> >>>> single
> >>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits
> where
> >>>> each
> >>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember
> >>>> why we
> >>>>>>>> went
> >>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
> >>>> somewhere, but
> >>>>>>>>>>>> one of
> >>>>>>>>>>>>>>> the nice things it provides is the ability for the release
> >>>> manager
> >>>>>>>> to
> >>>>>>>>>>>>>>> control what changes are made during code freeze while
> giving
> >>>>>>>> people a
> >>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not always
> >>>>>>>> followed).
> >>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have
> their
> >>>> own
> >>>>>>>>>>>> repo and
> >>>>>>>>>>>>>>> issue pull requests for bugfixes?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> >>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
> >>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> >>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
> >>>>>>>>>>>> merge(merge -s
> >>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
> >>>> bring in
> >>>>>>>> any
> >>>>>>>>>>>>>>>> changes.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a major
> >>>>>>>> rewrite, we
> >>>>>>>>>>>>>>>> could stop merging to that branch and above and make the
> fix
> >>>>>>>> manually.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a
> particular fix
> >>>>>>>> for an
> >>>>>>>>>>>> old
> >>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does
> happen.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to branch
> x"
> >>>> in
> >>>>>>>> SVN
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
> >>>> branch(es).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
> versions, or
> >>>>>>>> has to
> >>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
> changed?
> >>>>>>>> Don't
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after
> that?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> Stephen Turner
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
> mike.tutkowski@solidfire.com]
> >>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
> >>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
> >>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
> >>>> consider.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be error
> >>>> prone
> >>>>>>>> in
> >>>>>>>>>>>> that
> >>>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
> applicable
> >>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
> >>>>>>>> related.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to
> see
> >>>> if you
> >>>>>>>>>>>>>>>> checked a
> >>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In
> such a
> >>>>>>>>>>>> situation,
> >>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
> check-in
> >>>>>>>> was no
> >>>>>>>>>>>>>>>> longer
> >>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to
> mark
> >>>> it as
> >>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure
> about
> >>>> Git).
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the
> *forward
> >>>>>>>> branches
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all
> releases the
> >>>>>>>> commit
> >>>>>>>>>>>> has
> >>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
> >>>>>>>>>>>> contributor, I
> >>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
> >>>> cleanly
> >>>>>>>>>>>> apply on
> >>>>>>>>>>>>>>>>>>>> different branches.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
> >>>>>>>> propose.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major release(ex:
> >>>> 4.3.x,
> >>>>>>>>>>>> 4.4.x,
> >>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
> >>>>>>>> accordingly
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>> the respective branches.
> >>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed.
> Many
> >>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
> >>>>>>>> cherry-pick,
> >>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
> >>>> change or
> >>>>>>>>>>>> fix and
> >>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
> release
> >>>>>>>> branches
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should
> be
> >>>>>>>>>>>> merged(either
> >>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
> >>>> trackable
> >>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>> git branch --contains
> >>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
> release
> >>>>>>>> uptill
> >>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
> >>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> >>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time
> a
> >>>> new
> >>>>>>>> commit
> >>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>> done this will also get merged.
> >>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
> master
> >>>> to
> >>>>>>>>>>>> feature
> >>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
> >>>> proactively
> >>>>>>>>>>>> take
> >>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
> master
> >>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
> master on
> >>>>>>>> code
> >>>>>>>>>>>>>>>>>>>> complete through a merge.
> >>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
> release
> >>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor
> >>>> release)
> >>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
> information
> >>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed
> by
> >>>>>>>>>>>>>>>> <committer>
> >>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
> >>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
> freeze),
> >>>>>>>> any bug
> >>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
> >>>> release(4.4)
> >>>>>>>> only
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
> branch.
> >>>>>>>> This
> >>>>>>>>>>>> can be
> >>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be using
> >>>> jira
> >>>>>>>> vote?)
> >>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another
> branch
> >>>>>>>>>>>>>>>> maintenance.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Ref:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ~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
> >*™*
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> *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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>>
> >>>>>>> *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.
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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>*™*
> >>
> >
> >
> >
> > --
> > 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: [DISCUSS][PROPOSAL] git workflow

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

That's where the 4.5-hotfixes branch comes in.

On Thu, Jul 24, 2014 at 8:39 AM, Rajani Karuturi
<Ra...@citrix.com> wrote:
>
> Hi Daan,
> here is what i propose:
>
> 1. rename 'master' to 'develop’
> 2. branch a new 'master' from '4.4’
> 3. branch 'RELEASE-4.5' from the develop
> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>
> RELEASE-4.6 branch should be off develop as all the feature branches would be merged there before freeze for 4.6 and would be merged to master when the release is voted.
>
> The other question I have is in the step:4. how are we going to manage fixes to 4.5 post branch cut?  ( assuming no features as the freeze is done)
>
> ~Rajani
>
>
>
> On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com> wrote:
>
>> Mike, Rajani,
>>
>> Sebastien's point was that the current 4.4 is the closest we have to a
>> releasable branch. I don't mind enting on master but it will require
>> more fixing. In general all of this will require some RM work of all
>> committers. Please ammend my little proposal if you will.
>>
>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
>> <Ra...@citrix.com> wrote:
>>> I agree with mike. I think we should start 4.5 from where master is now
>>> Also create a develop branch from master and continue future work for 4.6 there.
>>>
>>> I am not clear on how the release branches are going to be maintained.
>>> Are we saying we would create 4.5-RELEASE branch which is essentially same as our current -FORWARD branch and continue cherry-picking?
>>>
>>> I would prefer merges to cherry-picks.
>>> Also, I think we should allow committers to commit to the RELEASE branch after discussing about it on dev@ and have RM closely monitor them.
>>> Any commit intended for 4.5 RELEASE should be checked in after discussion in the 4.5 Release branch and then merged to develop branch.
>>>
>>>
>>> ~Rajani
>>>
>>>
>>>
>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <mi...@solidfire.com> wrote:
>>>
>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4 left off
>>>> and then merge features from develop into 4.5.
>>>>
>>>> Why don't we instead start 4.5 where master is now with the assumption that
>>>> since we are past Feature Freeze for 4.5 that master is stable enough?
>>>>
>>>>
>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <da...@gmail.com>
>>>> wrote:
>>>>
>>>>> so to start formulate a proposal:
>>>>>
>>>>> all work shall be done in a new branch (it is advisable to prefix your
>>>>> branches with your id)
>>>>> when working, features will be cherry-picked/merged into the release
>>>>> branch they are for and next into master.
>>>>> hotfixes will be done in <branchname>-hotfixes
>>>>>
>>>>> as transition we will
>>>>>
>>>>> rename 'master' to 'develop'
>>>>> branch a new 'master' from '4.4'
>>>>> branch '4.5' from the new 'master'
>>>>> merge any features from the new 'develop' to '4.5' and 'master'
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <ru...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <ru...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com>
>>>>> wrote:
>>>>>>>
>>>>>>>> Let me ask the question, why have master be develop and a release
>>>>> branch be
>>>>>>>> "master"? If we are going to follow gitflow, why not just stick with
>>>>> the
>>>>>>>> norm? If master is the development branch, it might not be stable. I
>>>>> think
>>>>>>>> the goal here is that we have an obvious stable branch. Anyone could
>>>>> come
>>>>>>>> check out master and have the latest useable.
>>>>>>>
>>>>>>> I am in favor of following the norm, so ideally master should be our
>>>>> stable branch (agreed).
>>>>>>>
>>>>>>> The issue is with the transition.
>>>>>>>
>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally
>>>>> we could start a stable branch of this tag and build up bug fix releases
>>>>> all the way to 4.5 from there.
>>>>>>>
>>>>>>> But all features for 4.5 are already in master.
>>>>>>>
>>>>>>> So if we create a 'develop' branch of master and stabilize 'master'
>>>>> then develop is now started from a stable tag (4.4.0).
>>>>>>>
>>>>>>
>>>>>> *not* started from a stable tag, and merges will be tricky, no ?
>>>>>>
>>>>>>> So what's the best way to flip ? There is most likely some git magic
>>>>> that can we do.
>>>>>>>
>>>>>>>
>>>>>>> The new git workflow and the transition process need to be part of a
>>>>> proposal that we get consensus on.
>>>>>>>
>>>>>>> getting there :)
>>>>>>>
>>>>>>> -seb
>>>>>>>
>>>>>>>>
>>>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If you
>>>>>>>> completely squash history, you lose a tremendous amount of context,
>>>>> which I
>>>>>>>> use extensively to figure out why a bug is the way it is. Only knowing
>>>>> that
>>>>>>>> the branch was merged at a given point in time doesn't give any
>>>>> context.
>>>>>>>> Seeing the individual commit history of the branch helps to preserve
>>>>> the
>>>>>>>> rationale for why the code was written the way it was. In theory if
>>>>> every
>>>>>>>> change starts out as a branch (feature, hotfix, release), then why not
>>>>> just
>>>>>>>> merge the branch once it is in a good and acceptable state?
>>>>>>>>
>>>>>>>> I also agree with Mike that this will have to be a transition over
>>>>> time. It
>>>>>>>> will take some time to clean up master to the point where it can be
>>>>>>>> considered a solid stable branch. Possibly as part of the 4.5 release.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <runseb@gmail.com
>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Sebastien,
>>>>>>>>>>
>>>>>>>>>> It seems we can do what you are calling for is creating a branch
>>>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
>>>>> master,
>>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix in a
>>>>>>>>>> branch make a fork of that branch and when that fork is working do a
>>>>>>>>>> cherry-pick. The -forward concept is now used for that but it is
>>>>>>>>>> broken because more then for one piece of work there are commits on
>>>>>>>>>> it. This caused me conflicts during the release. Especially painfull
>>>>>>>>>> as not all was intended to get into the release. We can create this
>>>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
>>>>> changes.
>>>>>>>>>
>>>>>>>>> Yes, that's what I am thinking about too, so +1
>>>>>>>>>
>>>>>>>>> Our master would become the -develop- in gitflow terms
>>>>>>>>> The release branch you mention would become the -master- in gitflow
>>>>> terms
>>>>>>>>>
>>>>>>>>> If we start now, indeed we can create 'release' from 4.4 release tag
>>>>>>>>> (voted and shipped).
>>>>>>>>>
>>>>>>>>> That means that to create 4.5 we will need to merge features back into
>>>>>>>>> 'release'. it might be messy because some of those features are
>>>>> already in
>>>>>>>>> our current master.
>>>>>>>>>
>>>>>>>>> But all of this will keep 'release' clean (we can keep track of bugs
>>>>> and
>>>>>>>>> features that are in it in CHANGES file etc..)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> There is a question of control. Do we allow all committers to manage
>>>>>>>>>> the release? I am for that but can imagine not everybody is.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> At first I would say that only the RM can commit to 'release'. As we
>>>>> get
>>>>>>>>> the CI in place  we could relax this and allow commits that pass the
>>>>> CI to
>>>>>>>>> get into 'release', but right now I would vote for a tighter control
>>>>> of
>>>>>>>>> 'release'.
>>>>>>>>>
>>>>>>>>>> rule number 1 will be: you are going to do something to the code, you
>>>>>>>>>> start by creating a branch.
>>>>>>>>>>
>>>>>>>>>> right?
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
>>>>> runseb@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hey everyone,
>>>>>>>>>>>>
>>>>>>>>>>>> I've been a developer for a handful of years and have had my share
>>>>> of
>>>>>>>>>>>> experience with different version control systems.  I've used (for
>>>>>>>>> better
>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>>>>>>>>>>>
>>>>>>>>>>>> Each of these solutions offers their own unique set of features,
>>>>>>>>> strengths
>>>>>>>>>>>> and weaknesses.  As there are so many systems that are good at
>>>>> specific
>>>>>>>>>>>> things, it seems best to use the features that the chosen system is
>>>>>>>>> best at.
>>>>>>>>>>>>
>>>>>>>>>>>> Git is great at branching, merging and using that structure to
>>>>>>>>> maintain and
>>>>>>>>>>>> control how changes get into the primary branches.  Git tools even
>>>>> make
>>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
>>>>> branching
>>>>>>>>> and
>>>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to NOT
>>>>> make
>>>>>>>>> use
>>>>>>>>>>>> of these built-in capabilities.
>>>>>>>>>>>>
>>>>>>>>>>>> In addition to that, I know that the current method of change
>>>>>>>>> management is
>>>>>>>>>>>> incredibly frustrating to work with, and works directly against the
>>>>>>>>> way a
>>>>>>>>>>>> typical Git user would expect it to be structured.  I should NEVER
>>>>> have
>>>>>>>>>>>> problem compiling and running something on master.  I should not
>>>>> have
>>>>>>>>>>>> problems building anything on a release branch.  A feature/bugfix
>>>>>>>>> branch is
>>>>>>>>>>>> where things can be, and often are, broken or unstable.  There have
>>>>>>>>> been
>>>>>>>>>>>> many times working in Cloudstack where I've had to search for a
>>>>> stable
>>>>>>>>>>>> revision on master, and that's just plain wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> I do realize that having this many developers working on so many
>>>>>>>>> features
>>>>>>>>>>>> and bugfixes will result in a large number of branches.  I don't
>>>>>>>>> believe
>>>>>>>>>>>> this is a good argument against using a branching method, though -
>>>>> I
>>>>>>>>>>>> believe that the current system is even more confusing and
>>>>> difficult
>>>>>>>>> to use.
>>>>>>>>>>>>
>>>>>>>>>>>> I could pontificate on change management quite a bit more, but my
>>>>>>>>> opinion
>>>>>>>>>>>> in summary would basically be:  use Git the way it was meant to be
>>>>>>>>> used,
>>>>>>>>>>>> and things will be better.  Just my two cents.
>>>>>>>>>>>>
>>>>>>>>>>>> Sam
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Sam, I think we are in agreement (at least with folks who responded
>>>>> to
>>>>>>>>> this thread).
>>>>>>>>>>> Or maybe I am not reading your mail right and you don't agree with
>>>>> Leo ?
>>>>>>>>>>>
>>>>>>>>>>> My own take and reason for calling for a change we are currently
>>>>> doing
>>>>>>>>> things is mostly due to the way we release.
>>>>>>>>>>>
>>>>>>>>>>> I would like to see a stable master (and I think we are in agreement
>>>>>>>>> with that).
>>>>>>>>>>> That means that development should not happen on master and that
>>>>> every
>>>>>>>>> commit that lands on master should be shippable.
>>>>>>>>>>>
>>>>>>>>>>> I personally have no issues with cherry-picking. So I would be fine
>>>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
>>>>>>>>>>> The end result is that the next commit on master would still mean
>>>>>>>>> master is shippable/releasable.
>>>>>>>>>>>
>>>>>>>>>>> If we agree with this basic concept. The question becomes how do we
>>>>> get
>>>>>>>>> there, considering that master is now full of dev work and potential
>>>>> bug.
>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and previous
>>>>>>>>> release branches.
>>>>>>>>>>>
>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our way
>>>>> back,
>>>>>>>>> merging the new features that are already in master into the new
>>>>> master
>>>>>>>>> (based on 4.4).
>>>>>>>>>>> This could be quite complicated but we need to do it (or something
>>>>> like
>>>>>>>>> it).
>>>>>>>>>>>
>>>>>>>>>>> To move forward, we should make a proposal to the list and call for
>>>>> a
>>>>>>>>> vote.
>>>>>>>>>>>
>>>>>>>>>>> Any takers to start a wiki page proposing a new git process and how
>>>>> we
>>>>>>>>> could move to it (transition path) ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -Sebastien
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>>>>>>>>> LSimons@schubergphilis.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey folks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and implement
>>>>> this?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
>>>>>>>>> committer so
>>>>>>>>>>>>> its not that practical for me to volunteer!
>>>>>>>>>>>>>
>>>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>>>>>>>>>>>
>>>>>>>>>>>>> which might be easier to read.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Similarly, the git-flow scripts that help out with implementing
>>>>> this
>>>>>>>>> stuff
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://github.com/nvie/gitflow
>>>>>>>>>>>>>
>>>>>>>>>>>>> they also describe the relationship between gitflow and dealing
>>>>> with
>>>>>>>>>>>>> multiple remotes
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>>>>>>>>>>>>>
>>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in support
>>>>> for
>>>>>>>>>>>>> git-flow
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://www.sourcetreeapp.com/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because cloudstack currently is full of rebasing and squashing and
>>>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
>>>>> visualization
>>>>>>>>> tool
>>>>>>>>>>>>> (like this or gitk or ...) right now, but it would be *great* to
>>>>> have
>>>>>>>>> going
>>>>>>>>>>>>> forward.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> cheers,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Leo
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <runseb@gmail.com
>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would like to re-start this discussion.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thinking about our release procedure, we clearly need more tests
>>>>> and
>>>>>>>>> a
>>>>>>>>>>>>> CI. However it looks like this is going to take some time.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
>>>>> agreeing
>>>>>>>>> to
>>>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just need to
>>>>>>>>> agree on
>>>>>>>>>>>>> the git workflow.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right now Master is really a development branch, we should make
>>>>> it a
>>>>>>>>>>>>> stable branch for production with very few commits.
>>>>>>>>>>>>>> This does not mean that we would release less, in contrary this
>>>>> would
>>>>>>>>>>>>> ensure that a commit to master means it's a production release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back to
>>>>>>>>> Rajani's
>>>>>>>>>>>>> point) everything is based on merges.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am of the opinion that git flow provides a nice process. It
>>>>>>>>> basically
>>>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
>>>>> releases
>>>>>>>>>>>>> branches are branched off of that and merged into master and back
>>>>> into
>>>>>>>>>>>>> develop….etc
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please read [1] it's a good read.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And let's discuss,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Sebastien
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There is also the problem of cherry-picking.
>>>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches for
>>>>> each
>>>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches. which
>>>>> means
>>>>>>>>>>>>> distinct commits for each branch and I don’t easily know which all
>>>>>>>>> branches
>>>>>>>>>>>>> my commit exists unless I do grep.
>>>>>>>>>>>>>>> if we follow merging strategy properly, apart from the first
>>>>> merge
>>>>>>>>> of
>>>>>>>>>>>>> the branch, everything else on top of it should be a painless
>>>>> merge.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think many of the bullet points are what we are currently
>>>>> doing
>>>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to stay
>>>>> in
>>>>>>>>> sync
>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> master, no back-merging). I also think that much of what we do
>>>>> now
>>>>>>>>> is
>>>>>>>>>>>>> done
>>>>>>>>>>>>>>>> the way it is simply because there *are* vast changes between
>>>>>>>>> versions.
>>>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the time.
>>>>> If
>>>>>>>>> its
>>>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine, but some
>>>>>>>>> quick
>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with having
>>>>> single
>>>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits where
>>>>> each
>>>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember
>>>>> why we
>>>>>>>>> went
>>>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
>>>>> somewhere, but
>>>>>>>>>>>>> one of
>>>>>>>>>>>>>>>> the nice things it provides is the ability for the release
>>>>> manager
>>>>>>>>> to
>>>>>>>>>>>>>>>> control what changes are made during code freeze while giving
>>>>>>>>> people a
>>>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not always
>>>>>>>>> followed).
>>>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have their
>>>>> own
>>>>>>>>>>>>> repo and
>>>>>>>>>>>>>>>> issue pull requests for bugfixes?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
>>>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>>>>>>>>>>>>> merge(merge -s
>>>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
>>>>> bring in
>>>>>>>>> any
>>>>>>>>>>>>>>>>> changes.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a major
>>>>>>>>> rewrite, we
>>>>>>>>>>>>>>>>> could stop merging to that branch and above and make the fix
>>>>>>>>> manually.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a particular fix
>>>>>>>>> for an
>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does happen.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to branch x"
>>>>> in
>>>>>>>>> SVN
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
>>>>> branch(es).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
>>>>>>>>> has to
>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has changed?
>>>>>>>>> Don't
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Stephen Turner
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
>>>>> consider.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be error
>>>>> prone
>>>>>>>>> in
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
>>>>>>>>> related.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to see
>>>>> if you
>>>>>>>>>>>>>>>>> checked a
>>>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In such a
>>>>>>>>>>>>> situation,
>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
>>>>>>>>> was no
>>>>>>>>>>>>>>>>> longer
>>>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to mark
>>>>> it as
>>>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure about
>>>>> Git).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the *forward
>>>>>>>>> branches
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
>>>>>>>>> commit
>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>>>>>>>>>>>>> contributor, I
>>>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
>>>>> cleanly
>>>>>>>>>>>>> apply on
>>>>>>>>>>>>>>>>>>>>> different branches.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
>>>>>>>>> propose.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major release(ex:
>>>>> 4.3.x,
>>>>>>>>>>>>> 4.4.x,
>>>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>>>>>>>>> accordingly
>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>> the respective branches.
>>>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
>>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
>>>>>>>>> cherry-pick,
>>>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
>>>>> change or
>>>>>>>>>>>>> fix and
>>>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from release
>>>>>>>>> branches
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
>>>>>>>>>>>>> merged(either
>>>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
>>>>> trackable
>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> git branch --contains
>>>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal release
>>>>>>>>> uptill
>>>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time a
>>>>> new
>>>>>>>>> commit
>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from master
>>>>> to
>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
>>>>> proactively
>>>>>>>>>>>>> take
>>>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to master on
>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>> complete through a merge.
>>>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to release
>>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor
>>>>> release)
>>>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author information
>>>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>>>>>>>>>>>>>>>>> <committer>
>>>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
>>>>>>>>> any bug
>>>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
>>>>> release(4.4)
>>>>>>>>> only
>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release branch.
>>>>>>>>> This
>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be using
>>>>> jira
>>>>>>>>> vote?)
>>>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another branch
>>>>>>>>>>>>>>>>> maintenance.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ref:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ~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>*™*
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> *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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>> *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.
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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>*™*
>>>
>>
>>
>>
>> --
>> Daan
>



-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

It makes sense to me now. +1 from me

one minor thing i would like to add is git-flow doesn’t force you to its naming convention. You can choose any and stick to it. But, it makes sense to use the defaults.

~Rajani



On 24-Jul-2014, at 2:52 pm, Leo Simons <LS...@schubergphilis.com> wrote:

> On Jul 24, 2014, at 10:45 AM, Daan Hoogland <da...@gmail.com> wrote:
>> Any advice on our procedure from this, Leo?
> 
> Yes, to follow all the git-flow defaults [1].
> 
> * goal is for master to become stable
> * new develop which starts from master
>  * create with `git flow init`
> * ‘abandon’ 4.4 / 4.4-forward
>  * anything in there which is not currently
>    in master gets cherry-picked into develop
>  * accordingly, plan is no 4.4.1
>  * if 4.4.1 becomes really necessary, create
>    it by cherry-picking from develop
> * keep 4.3 to produce 4.3.1 then
>  abandon it, too
> 
> It is important to realize that a git-flow release/4.5 is _not_ the same as an old-style 4.5-forward; a lot more discipline is required.
> 
> 4.4-forward contains a lot of things which are not purely bugfixes. 4.4-forward has additional tests, lots of changes to test suites, things that should go in 4.4.1 but not 4.4.0, half-merged features that were pulled from 4.4 but remain in 4.4-forward, bugfixes that include refactoring, etc etc. In a git-flow model, those things would go onto feature/ and/or support/ branches, and from there to the develop branch, and definitiely _never_ onto a release branch. It was very hard to get 4.4 stable by cherry-picking from 4.4-forward; the discipline suggested by git-flow is _exactly_ to avoid that difficulty.
> 
> Note git-flow defaults also include:
> * feature branches are called feature/feature-thing
>  (don’t put your name in there, its meant to be
>  descriptive!)
> * release branches are called release/{version}
>  (not RELEASE-{version})
> * hotfixes are called hotfix/{version}-name
>  and are based on & merge to master (not usually
>  to a release branch, release branches are not
>  hot, hotfixes are patches to previous releases,
>  i.e. 4.5.1, 4.5.2, 4.5.3 will be hotfixes)
> * everyone can commit on release branches,
>  everyone can merge to develop (generally you
>  don’t need much merging to release branches
>  since the only thing you commit there are
>  bugfixes, you merge _from_ the release branch
>  _to_ the develop branch), merging is _not_ a
>  release manager's job (the release manager might
>  review or approve bugfixes, but its the committer
>  that merges)
> * no cherry-picking!
> 
> 
> cheers,
> 
> 
> Leo
> 
> [1] unfortunately, the reason I did this analysis work yesterday was to try and find a way to start from 4.4 and go forward from there, first merging in 4.4-forward and then master, but I don’t see that happening
> 
>> On Thu, Jul 24, 2014 at 10:39 AM, Leo Simons <LS...@schubergphilis.com> wrote:
>>>             branch two    diff size   big diff chunks
>>> branch one
>>> 4.3         4.4           11MB        hyperv,netscaler,server,engine
>>> 4.4         4.4-forward    2MB        tests,marvin
>>> 4.4-forward master         6MB        xenapi,xen,xenserver,storage
>>> 4.4         master         8MB        xenapi,tests,marvin,xen,xenserver
>>> (See below how I got the numbers.)
>>> 
>>> Starting git-flow from 4.4 or 4.4-forward and then merging things in from master means processing hundreds of thousands of lines of diff. Of those lines, many many thousands of lines will probably not auto-merge due to the cherry-pick approach. A rebase between any of these branches is not feasible; git cannot un-pick what happened so it cannot offer much assistance.
> 

Re: [DISCUSS][PROPOSAL] git workflow

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

If you are on Ubuntu (and who isn't these days... right?), you can install
git-flow easily (git-completion is nice as well)

aptitude install git-flow git-completion

and git-flow command completion is nice

https://github.com/bobthecow/git-flow-completion


On Thu, Jul 24, 2014 at 12:36 PM, Stephen Turner <St...@citrix.com>
wrote:

> I agree, every new ticket should be on a new branch. If you have two
> changesets you might ever want to merge separately, put them on separate
> branches.
>
> --
> Stephen Turner
>
>
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: 24 July 2014 17:30
> To: dev
> Subject: Re: [DISCUSS][PROPOSAL] git workflow
>
> On Thu, Jul 24, 2014 at 5:08 PM, Tracy Phillips <tr...@weberize.com>
> wrote:
> > Good read
> > http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>
>
> he agrees with our thread that every work sould start with creating a
> branch, doesn't he. I think we need to say that a lot of times more.
> Start a new branch when picking up a ticket. Start a new branch when
> experimenting on a new feature. Start a new branch when bored.
>
> --
> Daan
>

RE: [DISCUSS][PROPOSAL] git workflow

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

I agree, every new ticket should be on a new branch. If you have two changesets you might ever want to merge separately, put them on separate branches.

-- 
Stephen Turner


-----Original Message-----
From: Daan Hoogland [mailto:daan.hoogland@gmail.com] 
Sent: 24 July 2014 17:30
To: dev
Subject: Re: [DISCUSS][PROPOSAL] git workflow

On Thu, Jul 24, 2014 at 5:08 PM, Tracy Phillips <tr...@weberize.com> wrote:
> Good read 
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html


he agrees with our thread that every work sould start with creating a branch, doesn't he. I think we need to say that a lot of times more.
Start a new branch when picking up a ticket. Start a new branch when experimenting on a new feature. Start a new branch when bored.

--
Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

Yes, that is what he is saying. Its really the git way.

Starting a branch with the ticket-id and short description works best.

I think this is what you are looking for
https://wiki.diasporafoundation.org/Git_workflow


On Thu, Jul 24, 2014 at 12:29 PM, Daan Hoogland <da...@gmail.com>
wrote:

> On Thu, Jul 24, 2014 at 5:08 PM, Tracy Phillips <tr...@weberize.com>
> wrote:
> > Good read
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>
>
> he agrees with our thread that every work sould start with creating a
> branch, doesn't he. I think we need to say that a lot of times more.
> Start a new branch when picking up a ticket. Start a new branch when
> experimenting on a new feature. Start a new branch when bored.
>
> --
> Daan
>

Re: [DISCUSS][PROPOSAL] git workflow

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

On Thu, Jul 24, 2014 at 5:08 PM, Tracy Phillips <tr...@weberize.com> wrote:
> Good read http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html


he agrees with our thread that every work sould start with creating a
branch, doesn't he. I think we need to say that a lot of times more.
Start a new branch when picking up a ticket. Start a new branch when
experimenting on a new feature. Start a new branch when bored.

-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

The best thread I have read in awhile...

Good read http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html



On Thu, Jul 24, 2014 at 8:06 AM, Daan Hoogland <da...@gmail.com>
wrote:

> On Thu, Jul 24, 2014 at 1:43 PM, Leo Simons <LS...@schubergphilis.com>
> wrote:
> > lsimons
>
>
> has access
>
> --
> Daan
>

Re: [DISCUSS][PROPOSAL] git workflow

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

On Thu, Jul 24, 2014 at 1:43 PM, Leo Simons <LS...@schubergphilis.com> wrote:
> lsimons


has access

-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

On Jul 24, 2014, at 1:19 PM, Daan Hoogland <da...@gmail.com> wrote:
> Leo, are you prepared to write up a how-to cwiki page?

Sure, though it would be good to get a few provisional +1s before spending a lot of time drawing pretty pictures :)

Also, I don’t seem to have edit permissions on https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Maintainers+Guide . Can you add ‘lsimons’ to cloudstack confluence?


cheers,


Leo

Re: [DISCUSS][PROPOSAL] git workflow

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

now we are kind of set back by this unfortunate result of Leo's work.

new proposal:

We start using git-flow for 4.5/5.0 exclusively.
as of then we will use the workflows as describe by him [1]
4.4.x will still be released by manual RM-cherry-picking (yes
volunteer dragging his feet)

Leo, are you prepared to write up a how-to cwiki page?

kind regards,

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



On Thu, Jul 24, 2014 at 11:22 AM, Leo Simons <LS...@schubergphilis.com> wrote:
> On Jul 24, 2014, at 10:45 AM, Daan Hoogland <da...@gmail.com> wrote:
>> Any advice on our procedure from this, Leo?
>
> Yes, to follow all the git-flow defaults [1].
>
> * goal is for master to become stable
> * new develop which starts from master
>   * create with `git flow init`
> * ‘abandon’ 4.4 / 4.4-forward
>   * anything in there which is not currently
>     in master gets cherry-picked into develop
>   * accordingly, plan is no 4.4.1
>   * if 4.4.1 becomes really necessary, create
>     it by cherry-picking from develop
> * keep 4.3 to produce 4.3.1 then
>   abandon it, too
>
> It is important to realize that a git-flow release/4.5 is _not_ the same as an old-style 4.5-forward; a lot more discipline is required.
>
> 4.4-forward contains a lot of things which are not purely bugfixes. 4.4-forward has additional tests, lots of changes to test suites, things that should go in 4.4.1 but not 4.4.0, half-merged features that were pulled from 4.4 but remain in 4.4-forward, bugfixes that include refactoring, etc etc. In a git-flow model, those things would go onto feature/ and/or support/ branches, and from there to the develop branch, and definitiely _never_ onto a release branch. It was very hard to get 4.4 stable by cherry-picking from 4.4-forward; the discipline suggested by git-flow is _exactly_ to avoid that difficulty.
>
> Note git-flow defaults also include:
> * feature branches are called feature/feature-thing
>   (don’t put your name in there, its meant to be
>   descriptive!)
> * release branches are called release/{version}
>   (not RELEASE-{version})
> * hotfixes are called hotfix/{version}-name
>   and are based on & merge to master (not usually
>   to a release branch, release branches are not
>   hot, hotfixes are patches to previous releases,
>   i.e. 4.5.1, 4.5.2, 4.5.3 will be hotfixes)
> * everyone can commit on release branches,
>   everyone can merge to develop (generally you
>   don’t need much merging to release branches
>   since the only thing you commit there are
>   bugfixes, you merge _from_ the release branch
>   _to_ the develop branch), merging is _not_ a
>   release manager's job (the release manager might
>   review or approve bugfixes, but its the committer
>   that merges)
> * no cherry-picking!
>
>
> cheers,
>
>
> Leo
>
> [1] unfortunately, the reason I did this analysis work yesterday was to try and find a way to start from 4.4 and go forward from there, first merging in 4.4-forward and then master, but I don’t see that happening
>
>> On Thu, Jul 24, 2014 at 10:39 AM, Leo Simons <LS...@schubergphilis.com> wrote:
>>>              branch two    diff size   big diff chunks
>>>  branch one
>>>  4.3         4.4           11MB        hyperv,netscaler,server,engine
>>>  4.4         4.4-forward    2MB        tests,marvin
>>>  4.4-forward master         6MB        xenapi,xen,xenserver,storage
>>>  4.4         master         8MB        xenapi,tests,marvin,xen,xenserver
>>>  (See below how I got the numbers.)
>>>
>>> Starting git-flow from 4.4 or 4.4-forward and then merging things in from master means processing hundreds of thousands of lines of diff. Of those lines, many many thousands of lines will probably not auto-merge due to the cherry-pick approach. A rebase between any of these branches is not feasible; git cannot un-pick what happened so it cannot offer much assistance.
>



-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

On Jul 24, 2014, at 10:45 AM, Daan Hoogland <da...@gmail.com> wrote:
> Any advice on our procedure from this, Leo?

Yes, to follow all the git-flow defaults [1].

* goal is for master to become stable
* new develop which starts from master
  * create with `git flow init`
* ‘abandon’ 4.4 / 4.4-forward
  * anything in there which is not currently
    in master gets cherry-picked into develop
  * accordingly, plan is no 4.4.1
  * if 4.4.1 becomes really necessary, create
    it by cherry-picking from develop
* keep 4.3 to produce 4.3.1 then
  abandon it, too

It is important to realize that a git-flow release/4.5 is _not_ the same as an old-style 4.5-forward; a lot more discipline is required.

4.4-forward contains a lot of things which are not purely bugfixes. 4.4-forward has additional tests, lots of changes to test suites, things that should go in 4.4.1 but not 4.4.0, half-merged features that were pulled from 4.4 but remain in 4.4-forward, bugfixes that include refactoring, etc etc. In a git-flow model, those things would go onto feature/ and/or support/ branches, and from there to the develop branch, and definitiely _never_ onto a release branch. It was very hard to get 4.4 stable by cherry-picking from 4.4-forward; the discipline suggested by git-flow is _exactly_ to avoid that difficulty.

Note git-flow defaults also include:
* feature branches are called feature/feature-thing
  (don’t put your name in there, its meant to be
  descriptive!)
* release branches are called release/{version}
  (not RELEASE-{version})
* hotfixes are called hotfix/{version}-name
  and are based on & merge to master (not usually
  to a release branch, release branches are not
  hot, hotfixes are patches to previous releases,
  i.e. 4.5.1, 4.5.2, 4.5.3 will be hotfixes)
* everyone can commit on release branches,
  everyone can merge to develop (generally you
  don’t need much merging to release branches
  since the only thing you commit there are
  bugfixes, you merge _from_ the release branch
  _to_ the develop branch), merging is _not_ a
  release manager's job (the release manager might
  review or approve bugfixes, but its the committer
  that merges)
* no cherry-picking!


cheers,


Leo

[1] unfortunately, the reason I did this analysis work yesterday was to try and find a way to start from 4.4 and go forward from there, first merging in 4.4-forward and then master, but I don’t see that happening

> On Thu, Jul 24, 2014 at 10:39 AM, Leo Simons <LS...@schubergphilis.com> wrote:
>>              branch two    diff size   big diff chunks
>>  branch one
>>  4.3         4.4           11MB        hyperv,netscaler,server,engine
>>  4.4         4.4-forward    2MB        tests,marvin
>>  4.4-forward master         6MB        xenapi,xen,xenserver,storage
>>  4.4         master         8MB        xenapi,tests,marvin,xen,xenserver
>>  (See below how I got the numbers.)
>> 
>> Starting git-flow from 4.4 or 4.4-forward and then merging things in from master means processing hundreds of thousands of lines of diff. Of those lines, many many thousands of lines will probably not auto-merge due to the cherry-pick approach. A rebase between any of these branches is not feasible; git cannot un-pick what happened so it cannot offer much assistance.

Re: [DISCUSS][PROPOSAL] git workflow

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

Any advice on our procedure from this, Leo?

On Thu, Jul 24, 2014 at 10:39 AM, Leo Simons <LS...@schubergphilis.com> wrote:
> On Jul 24, 2014, at 8:39 AM, Rajani Karuturi <Ra...@citrix.com> wrote:
>> here is what i propose:
>>
>> 1. rename 'master' to 'develop’
>> 2. branch a new 'master' from '4.4’
>> 3. branch 'RELEASE-4.5' from the develop
>> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>
> I like this conceptually; I’m not sure if its feasible because step 4 requires resolving the cherry-pick mess.
>
> Ignoring awsapi (which has a lot of churn) and ignoring formatting changes, here are sizes of very minimalized diffs between branches
>
>               branch two    diff size   big diff chunks
>   branch one
>   4.3         4.4           11MB        hyperv,netscaler,server,engine
>   4.4         4.4-forward    2MB        tests,marvin
>   4.4-forward master         6MB        xenapi,xen,xenserver,storage
>   4.4         master         8MB        xenapi,tests,marvin,xen,xenserver
>   (See below how I got the numbers.)
>
> Starting git-flow from 4.4 or 4.4-forward and then merging things in from master means processing hundreds of thousands of lines of diff. Of those lines, many many thousands of lines will probably not auto-merge due to the cherry-pick approach. A rebase between any of these branches is not feasible; git cannot un-pick what happened so it cannot offer much assistance.
>
> Looking at all the diff stats, breaking xenapi and awsapi out into their own git repositories (and release cycles) seems like a really good thing to do; I expect it will help a lot with future merges.
>
> You can try step 4. for yourself now:
>
>   git checkout 4.4
>   git merge master
>
> Good luck ;-)
>
>> RELEASE-4.6 branch should be off develop as all the feature branches would be merged there before freeze for 4.6 and would be merged to master when the release is voted.
>
> Small note, git-flow tends to use release/ prefixes for release branches. You'd label ‘em
>
>   master
>   develop
>   feature/nuage-vsp-support
>   feature/frob-the-foo
>   support/license-header-update
>   release/4.5
>   release/4.6
>
>> The other question I have is in the step:4. how are we going to manage fixes to 4.5 post branch cut?  ( assuming no features as the freeze is done)
>
> Yes that’d be typical with git-flow. Once you create the release branch, all bugfixes that are to make it into that release go onto the release branch _first_ (and _only_ fixes go there), before being merged into develop.
>
> With git-flow you don’t really have to call it a “freeze”. Development of new features continues (on their feature branches) uninterrupted even if a release is being cut, and merging of completed features still is exactly the same (to develop) regardless of whether there’s active release branches.
>
> On many projects using git-flow there is no rush to try and get features merged before a release cut-off date, because cutting another release is easy and cheap that you can just do one ‘whenever’ to get your feature out there.
>
> For cloudstack that’s not quite the case due to the somewhat heavyweight test/release process. What I imagine is that if a feature misses a deadline, and the community decides it wants to include that feature anyway, is rebasing it onto the release branch and merging it
>
>   ...decide a finished feature goes into 4.5 after all...
>   git branch feature/frob-the-foo-4.5 feature/frob-the-foo
>   git checkout feature/frob-the-foo-4.5
>   git rebase -i release/4.5
>   git push origin feature/frob-the-foo-4.5
>   git checkout release/4.5
>   git pull --rebase
>   git merge feature/frob-the-foo-4.5
>   git checkout develop
>   git pull --rebase
>   git merge release/4.5
>   git push
>   git branch -d feature/frob-the-foo-4.5
>   git branch -d feature/frob-the-foo
>
> There’s little to no chance cloudstack could ever safely decide to do this right now, but a few months down the road, this might become safe enough, especially since the two explicit merge commits allow figuring out what happened, and possibly rolling back if the feature destabilizes the release.
>
> Your workflow would be that most tests and most QA work runs on the release branch, while developers switch between release branch and develop branch depending on what they are doing. A developer that is picking up a bug report associated with that release will basically
>
>   ...get the bug report...
>   git stash save what-I-was-doing
>   git checkout release/4.5
>   git pull --rebase
>   ...code code code...
>   ...test...
>   git commit && git push
>   git checkout develop
>   git merge release/4.5
>   git push
>   git stash pop what-I-was-doing
>   ...code code code...
>
> For bigger amounts of change/experimentation to work on a nasty kind of bug, you might have your own local temporary branch (I almost always do this myself):
>
>   ...get the bug report...
>   git stash save what-I-was-doing
>   git checkout release/4.5
>   git pull --ff-only
>   git branch bugfix/CLOUDSTACK-42 release/4.5
>   git checkout bugfix/CLOUDSTACK-42
>   ...code code code...
>   git commit
>   ...code code code...
>   git commit
>   ...test...
>   git pull
>   git rebase -i release/4.5
>   git commit
>   git checkout release/4.5
>   git merge bugfix/CLOUDSTACK-42
>   git commit
>   git checkout develop
>   git merge release/4.5
>   git push origin develop release/4.5
>   git branch -d bugfix/CLOUDSTACK-12345
>   git stash pop what-I-was-doing
>   ...code code code...
>
> It’s a bit of adjustment, but once you get used to it, this lots-of-branching way of working is soooo much nicer than most alternatives :-)
>
>
> cheers,
>
>
> Leo
>
> PS: diff stats...
>
> $ git clean -f -x -d
>
> $ git remote -v
> lsimons git@github.com:lsimons/cloudstack.git (fetch)
> lsimons git@github.com:lsimons/cloudstack.git (push)
> origin  git://git.apache.org/cloudstack.git (fetch)
> origin  git://git.apache.org/cloudstack.git (push)
> sbpgh git@github.com:schubergphilis/cloudstack.git (fetch)
> sbpgh git@github.com:schubergphilis/cloudstack.git (push)
>
> # snapshot important branches
> git branch 4.3-201407231043 4.3
> git branch 4.4-201407231043 4.4
> git branch 4.4-forward-201407231043 4.4-forward
> git branch master-201407231043 master
>
> # create branches which reformat the important branches
> git branch 4.3-201407231043-format 4.3-201407231043
> git branch 4.4-201407231043-format 4.4-201407231043
> git branch 4.4-forward-201407231043-format 4.4-forward-201407231043
> git branch master-201407231043-format master-201407231043
>
> # patcher....this is pseudocode, the pom.xml patch doesn't work / apply cleanly
> #   across branches
> function patcher() {
> patch -p1 <<END
> diff --git a/pom.xml b/pom.xml
> index 3d1e747..ad792ac 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -463,6 +463,11 @@
>      <pluginManagement>
>        <plugins>
>          <plugin>
> +          <groupId>com.googlecode.maven-java-formatter-plugin</groupId>
> +          <artifactId>maven-java-formatter-plugin</artifactId>
> +          <version>0.4</version>
> +        </plugin>
> +        <plugin>
>            <artifactId>maven-clean-plugin</artifactId>
>            <configuration>
>              <excludeDefaultDirectories>true</excludeDefaultDirectories>
> END
> }
>
> # trick to reformatting all java code on a branch
> function formatter() {
>   git clean -f -x -d
>   git checkout $1
>   git clean -f -x -d
>   mvn com.googlecode.maven-java-formatter-plugin:maven-java-formatter-plugin:0.4:format
>   git add .
>   git commit -m "format"
> }
>
> formatter 4.3-201407231043-format
> formatter 4.4-201407231043-format
> formatter 4.4-forward-201407231043-format
> formatter master-201407231043-format
>
> # trick to get minimalistic diff between two branches
> function minimaldiff() {
>   git diff \
>    \
>     -U0 -M -C -w --ignore-blank-lines --find-copies-harder \
>     --diff-algorithm=minimal \
>     $1..$2 | egrep -v '^[+-] *#'
> }
>
> minimaldiff 4.3-201407231043-format 4.4-201407231043-format | > ~/4.3-to-4.4.txt
> 4.3-to-4.4.txt is a 31MB text file
>
> $ git diff --dirstat=lines,2,cumulative 4.3-201407231043-format 4.4-201407231043-format
>   37.9% awsapi/src/com/amazon/ec2/client/
>   76.5% awsapi/src/com/amazon/ec2/
>    3.5% awsapi/src/com/amazon/s3/client/
>    7.7% awsapi/src/com/amazon/s3/
>   84.2% awsapi/src/com/amazon/
>    2.5% awsapi/src/com/cloud/
>   86.7% awsapi/src/com/
>   86.7% awsapi/
>    4.3% plugins/
>
> 85% of the diff is in awsapi, so lets filter that out...
>
> git filter-branch \
>   --index-filter 'git rm -r --cached --ignore-unmatch awsapi' \
>   4.3-201407231043-format \
>   4.4-201407231043-format \
>   4.4-forward-201407231043-format \
>   master-201407231043-format
>
> minimaldiff 4.3-201407231043-format 4.4-201407231043-format > ~/4.3-to-4.4-no-aws.txt
> 4.3-to-4.4-no-aws.txt is a 11MB text file
>
> $ git diff --dirstat=lines,4 4.3-201407231043-format 4.4-201407231043-format
>    5.4% api/src/org/apache/cloudstack/api/command/
>    4.0% deps/XenServerJava/src/com/xensource/xenapi/
>    6.4% engine/
>    4.1% plugins/hypervisors/hyperv/DotNet/ServerResource/
>   10.3% plugins/hypervisors/
>    4.3% plugins/network-elements/netscaler/src/com/cloud/
>   10.0% plugins/network-elements/
>    8.1% server/src/com/cloud/
>    5.1% services/secondary-storage/
>    4.9% ui/scripts/
>    4.7% ui/
>    4.1% vmware-base/src/com/cloud/hypervisor/vmware/mo/
>
> minimaldiff 4.4-201407231043-format 4.4-forward-201407231043-format > ~/4.4-to-4.4.1-no-aws.txt
> ~/4.4-to-4.4.1-no-aws.txt is a 2MB text file
>
> $ git diff --dirstat=lines,2 4.4-201407231043-format 4.4-forward-201407231043-format
>    2.8% plugins/hypervisors/hyperv/DotNet/ServerResource/WmiWrappers/
>    2.4% plugins/hypervisors/
>   47.6% test/integration/component/
>    8.1% test/integration/smoke/
>    2.8% tools/marvin/marvin/config/
>    9.4% tools/marvin/marvin/integration/lib/
>   11.7% tools/marvin/marvin/lib/
>    6.9% tools/marvin/marvin/
>    2.2% ui/scripts/
>
> minimaldiff 4.4-201407231043-format master-201407231043-format > ~/4.4.0-to-4.5-no-aws.txt
> ~/4.4.0-to-4.5-no-aws.txt is a 7.7MB text file
>
> $ git diff --dirstat=lines,4 4.4-201407231043-format master-201407231043-format
>   26.5% deps/XenServerJava/src/com/xensource/xenapi/
>    9.8% plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/
>    9.7% plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resourc
>    4.9% plugins/hypervisors/
>    7.6% plugins/
>   13.1% test/integration/component/
>    8.8% tools/marvin/marvin/
>
> minimaldiff 4.4-forward-201407231043-format master-201407231043-format > ~/4.4.1-to-4.5-no-aws.txt
> ~/4.4.1-to-4.5-no-aws.txt is a 5.6MB text file
>
> $ git diff --dirstat=lines,4 4.4-forward-201407231043-format master-201407231043-format
>   35.4% deps/XenServerJava/src/com/xensource/xenapi/
>   13.1% plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/
>   13.0% plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resourc
>    4.6% plugins/hypervisors/
>    4.2% plugins/network-elements/
>    5.1% plugins/storage/volume/
>    4.1% scripts/
>    4.1% server/
>



-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

On Jul 24, 2014, at 8:39 AM, Rajani Karuturi <Ra...@citrix.com> wrote:
> here is what i propose:
> 
> 1. rename 'master' to 'develop’
> 2. branch a new 'master' from '4.4’
> 3. branch 'RELEASE-4.5' from the develop
> 4. merge 'RELEASE-4.5' to master once the release voting is done.

I like this conceptually; I’m not sure if its feasible because step 4 requires resolving the cherry-pick mess.

Ignoring awsapi (which has a lot of churn) and ignoring formatting changes, here are sizes of very minimalized diffs between branches

              branch two    diff size   big diff chunks
  branch one
  4.3         4.4           11MB        hyperv,netscaler,server,engine
  4.4         4.4-forward    2MB        tests,marvin
  4.4-forward master         6MB        xenapi,xen,xenserver,storage
  4.4         master         8MB        xenapi,tests,marvin,xen,xenserver
  (See below how I got the numbers.)

Starting git-flow from 4.4 or 4.4-forward and then merging things in from master means processing hundreds of thousands of lines of diff. Of those lines, many many thousands of lines will probably not auto-merge due to the cherry-pick approach. A rebase between any of these branches is not feasible; git cannot un-pick what happened so it cannot offer much assistance.

Looking at all the diff stats, breaking xenapi and awsapi out into their own git repositories (and release cycles) seems like a really good thing to do; I expect it will help a lot with future merges.

You can try step 4. for yourself now:

  git checkout 4.4
  git merge master

Good luck ;-)

> RELEASE-4.6 branch should be off develop as all the feature branches would be merged there before freeze for 4.6 and would be merged to master when the release is voted.

Small note, git-flow tends to use release/ prefixes for release branches. You'd label ‘em

  master
  develop
  feature/nuage-vsp-support
  feature/frob-the-foo
  support/license-header-update
  release/4.5
  release/4.6

> The other question I have is in the step:4. how are we going to manage fixes to 4.5 post branch cut?  ( assuming no features as the freeze is done)

Yes that’d be typical with git-flow. Once you create the release branch, all bugfixes that are to make it into that release go onto the release branch _first_ (and _only_ fixes go there), before being merged into develop.

With git-flow you don’t really have to call it a “freeze”. Development of new features continues (on their feature branches) uninterrupted even if a release is being cut, and merging of completed features still is exactly the same (to develop) regardless of whether there’s active release branches.

On many projects using git-flow there is no rush to try and get features merged before a release cut-off date, because cutting another release is easy and cheap that you can just do one ‘whenever’ to get your feature out there.

For cloudstack that’s not quite the case due to the somewhat heavyweight test/release process. What I imagine is that if a feature misses a deadline, and the community decides it wants to include that feature anyway, is rebasing it onto the release branch and merging it

  ...decide a finished feature goes into 4.5 after all...
  git branch feature/frob-the-foo-4.5 feature/frob-the-foo
  git checkout feature/frob-the-foo-4.5
  git rebase -i release/4.5
  git push origin feature/frob-the-foo-4.5
  git checkout release/4.5
  git pull --rebase
  git merge feature/frob-the-foo-4.5
  git checkout develop
  git pull --rebase
  git merge release/4.5
  git push
  git branch -d feature/frob-the-foo-4.5
  git branch -d feature/frob-the-foo

There’s little to no chance cloudstack could ever safely decide to do this right now, but a few months down the road, this might become safe enough, especially since the two explicit merge commits allow figuring out what happened, and possibly rolling back if the feature destabilizes the release.

Your workflow would be that most tests and most QA work runs on the release branch, while developers switch between release branch and develop branch depending on what they are doing. A developer that is picking up a bug report associated with that release will basically

  ...get the bug report...
  git stash save what-I-was-doing
  git checkout release/4.5
  git pull --rebase
  ...code code code...
  ...test...
  git commit && git push
  git checkout develop
  git merge release/4.5
  git push
  git stash pop what-I-was-doing
  ...code code code...

For bigger amounts of change/experimentation to work on a nasty kind of bug, you might have your own local temporary branch (I almost always do this myself):

  ...get the bug report...
  git stash save what-I-was-doing
  git checkout release/4.5
  git pull --ff-only
  git branch bugfix/CLOUDSTACK-42 release/4.5
  git checkout bugfix/CLOUDSTACK-42
  ...code code code...
  git commit
  ...code code code...
  git commit
  ...test...
  git pull
  git rebase -i release/4.5
  git commit
  git checkout release/4.5
  git merge bugfix/CLOUDSTACK-42
  git commit
  git checkout develop
  git merge release/4.5
  git push origin develop release/4.5
  git branch -d bugfix/CLOUDSTACK-12345
  git stash pop what-I-was-doing
  ...code code code...

It’s a bit of adjustment, but once you get used to it, this lots-of-branching way of working is soooo much nicer than most alternatives :-)


cheers,


Leo

PS: diff stats...

$ git clean -f -x -d

$ git remote -v
lsimons git@github.com:lsimons/cloudstack.git (fetch)
lsimons git@github.com:lsimons/cloudstack.git (push)
origin  git://git.apache.org/cloudstack.git (fetch)
origin  git://git.apache.org/cloudstack.git (push)
sbpgh git@github.com:schubergphilis/cloudstack.git (fetch)
sbpgh git@github.com:schubergphilis/cloudstack.git (push)

# snapshot important branches
git branch 4.3-201407231043 4.3
git branch 4.4-201407231043 4.4
git branch 4.4-forward-201407231043 4.4-forward
git branch master-201407231043 master

# create branches which reformat the important branches
git branch 4.3-201407231043-format 4.3-201407231043
git branch 4.4-201407231043-format 4.4-201407231043
git branch 4.4-forward-201407231043-format 4.4-forward-201407231043
git branch master-201407231043-format master-201407231043

# patcher....this is pseudocode, the pom.xml patch doesn't work / apply cleanly
#   across branches
function patcher() {
patch -p1 <<END
diff --git a/pom.xml b/pom.xml
index 3d1e747..ad792ac 100644
--- a/pom.xml
+++ b/pom.xml
@@ -463,6 +463,11 @@
     <pluginManagement>
       <plugins>
         <plugin>
+          <groupId>com.googlecode.maven-java-formatter-plugin</groupId>
+          <artifactId>maven-java-formatter-plugin</artifactId>
+          <version>0.4</version>
+        </plugin>
+        <plugin>
           <artifactId>maven-clean-plugin</artifactId>
           <configuration>
             <excludeDefaultDirectories>true</excludeDefaultDirectories>
END
}

# trick to reformatting all java code on a branch
function formatter() {
  git clean -f -x -d
  git checkout $1
  git clean -f -x -d
  mvn com.googlecode.maven-java-formatter-plugin:maven-java-formatter-plugin:0.4:format
  git add .
  git commit -m "format"
}

formatter 4.3-201407231043-format
formatter 4.4-201407231043-format
formatter 4.4-forward-201407231043-format
formatter master-201407231043-format

# trick to get minimalistic diff between two branches
function minimaldiff() {
  git diff \
   \
    -U0 -M -C -w --ignore-blank-lines --find-copies-harder \
    --diff-algorithm=minimal \
    $1..$2 | egrep -v '^[+-] *#'
}

minimaldiff 4.3-201407231043-format 4.4-201407231043-format | > ~/4.3-to-4.4.txt
4.3-to-4.4.txt is a 31MB text file

$ git diff --dirstat=lines,2,cumulative 4.3-201407231043-format 4.4-201407231043-format
  37.9% awsapi/src/com/amazon/ec2/client/
  76.5% awsapi/src/com/amazon/ec2/
   3.5% awsapi/src/com/amazon/s3/client/
   7.7% awsapi/src/com/amazon/s3/
  84.2% awsapi/src/com/amazon/
   2.5% awsapi/src/com/cloud/
  86.7% awsapi/src/com/
  86.7% awsapi/
   4.3% plugins/

85% of the diff is in awsapi, so lets filter that out...

git filter-branch \
  --index-filter 'git rm -r --cached --ignore-unmatch awsapi' \
  4.3-201407231043-format \
  4.4-201407231043-format \
  4.4-forward-201407231043-format \
  master-201407231043-format

minimaldiff 4.3-201407231043-format 4.4-201407231043-format > ~/4.3-to-4.4-no-aws.txt
4.3-to-4.4-no-aws.txt is a 11MB text file

$ git diff --dirstat=lines,4 4.3-201407231043-format 4.4-201407231043-format
   5.4% api/src/org/apache/cloudstack/api/command/
   4.0% deps/XenServerJava/src/com/xensource/xenapi/
   6.4% engine/
   4.1% plugins/hypervisors/hyperv/DotNet/ServerResource/
  10.3% plugins/hypervisors/
   4.3% plugins/network-elements/netscaler/src/com/cloud/
  10.0% plugins/network-elements/
   8.1% server/src/com/cloud/
   5.1% services/secondary-storage/
   4.9% ui/scripts/
   4.7% ui/
   4.1% vmware-base/src/com/cloud/hypervisor/vmware/mo/

minimaldiff 4.4-201407231043-format 4.4-forward-201407231043-format > ~/4.4-to-4.4.1-no-aws.txt
~/4.4-to-4.4.1-no-aws.txt is a 2MB text file

$ git diff --dirstat=lines,2 4.4-201407231043-format 4.4-forward-201407231043-format
   2.8% plugins/hypervisors/hyperv/DotNet/ServerResource/WmiWrappers/
   2.4% plugins/hypervisors/
  47.6% test/integration/component/
   8.1% test/integration/smoke/
   2.8% tools/marvin/marvin/config/
   9.4% tools/marvin/marvin/integration/lib/
  11.7% tools/marvin/marvin/lib/
   6.9% tools/marvin/marvin/
   2.2% ui/scripts/

minimaldiff 4.4-201407231043-format master-201407231043-format > ~/4.4.0-to-4.5-no-aws.txt
~/4.4.0-to-4.5-no-aws.txt is a 7.7MB text file

$ git diff --dirstat=lines,4 4.4-201407231043-format master-201407231043-format
  26.5% deps/XenServerJava/src/com/xensource/xenapi/
   9.8% plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/
   9.7% plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resourc
   4.9% plugins/hypervisors/
   7.6% plugins/
  13.1% test/integration/component/
   8.8% tools/marvin/marvin/

minimaldiff 4.4-forward-201407231043-format master-201407231043-format > ~/4.4.1-to-4.5-no-aws.txt
~/4.4.1-to-4.5-no-aws.txt is a 5.6MB text file

$ git diff --dirstat=lines,4 4.4-forward-201407231043-format master-201407231043-format
  35.4% deps/XenServerJava/src/com/xensource/xenapi/
  13.1% plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/
  13.0% plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resourc
   4.6% plugins/hypervisors/
   4.2% plugins/network-elements/
   5.1% plugins/storage/volume/
   4.1% scripts/
   4.1% server/

Re: [DISCUSS][PROPOSAL] git workflow

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

Hi Daan/Erik,

I am not asking about the next minor release or hot fix. But, about the process involved after cutting the release branch and before the release is votes. i.e.) making it stable and bug/blocker free.
currently, we do that through commit to 4.5-forward and cherry-pick requests. Are we going to continue with the commit rights only to RM for the release branch and cherry-picking?

I would prefer developers committing to the release-4.5 branch and then merging it to develop branch. But, before committing, developer should call out for a discussion on the dev@



~Rajani



On 24-Jul-2014, at 12:27 pm, Erik Weber <te...@gmail.com>> wrote:

24. juli 2014 08:39 skrev "Rajani Karuturi" <Ra...@citrix.com>>
følgende:


Hi Daan,
here is what i propose:

1. rename 'master' to 'develop’
2. branch a new 'master' from '4.4’
3. branch 'RELEASE-4.5' from the develop
4. merge 'RELEASE-4.5' to master once the release voting is done.

RELEASE-4.6 branch should be off develop as all the feature branches
would be merged there before freeze for 4.6 and would be merged to master
when the release is voted.

The other question I have is in the step:4. how are we going to manage
fixes to 4.5 post branch cut?  ( assuming no features as the freeze is done)

Sub releases, ie. 4.4.1,  is generally just hotfixes / bugfixes, yes? In
that case you can branch it off 'master' and merge back to master as a new
release after voting, and merge to develop if the fix is applicable there.

Erik

~Rajani



On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com>>
wrote:

Mike, Rajani,

Sebastien's point was that the current 4.4 is the closest we have to a
releasable branch. I don't mind enting on master but it will require
more fixing. In general all of this will require some RM work of all
committers. Please ammend my little proposal if you will.

On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
<Ra...@citrix.com>> wrote:
I agree with mike. I think we should start 4.5 from where master is now
Also create a develop branch from master and continue future work for
4.6 there.

I am not clear on how the release branches are going to be maintained.
Are we saying we would create 4.5-RELEASE branch which is essentially
same as our current -FORWARD branch and continue cherry-picking?

I would prefer merges to cherry-picks.
Also, I think we should allow committers to commit to the RELEASE
branch after discussing about it on dev@ and have RM closely monitor them.
Any commit intended for 4.5 RELEASE should be checked in after
discussion in the 4.5 Release branch and then merged to develop branch.


~Rajani



On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
mike.tutkowski@solidfire.com<ma...@solidfire.com>> wrote:

Per earlier e-mails, I don't think we want to start 4.5 where 4.4
left off
and then merge features from develop into 4.5.

Why don't we instead start 4.5 where master is now with the
assumption that
since we are past Feature Freeze for 4.5 that master is stable enough?


On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
daan.hoogland@gmail.com<ma...@gmail.com>>
wrote:

so to start formulate a proposal:

all work shall be done in a new branch (it is advisable to prefix
your
branches with your id)
when working, features will be cherry-picked/merged into the release
branch they are for and next into master.
hotfixes will be done in <branchname>-hotfixes

as transition we will

rename 'master' to 'develop'
branch a new 'master' from '4.4'
branch '4.5' from the new 'master'
merge any features from the new 'develop' to '4.5' and 'master'



On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <ru...@gmail.com>

wrote:

On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <ru...@gmail.com>>
wrote:


On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com>>
wrote:

Let me ask the question, why have master be develop and a release
branch be
"master"? If we are going to follow gitflow, why not just stick
with
the
norm? If master is the development branch, it might not be
stable. I
think
the goal here is that we have an obvious stable branch. Anyone
could
come
check out master and have the latest useable.

I am in favor of following the norm, so ideally master should be
our
stable branch (agreed).

The issue is with the transition.

Our latest releasable product is the 4.4 branch (4.4.0 tag), so
ideally
we could start a stable branch of this tag and build up bug fix
releases
all the way to 4.5 from there.

But all features for 4.5 are already in master.

So if we create a 'develop' branch of master and stabilize 'master'
then develop is now started from a stable tag (4.4.0).


*not* started from a stable tag, and merges will be tricky, no ?

So what's the best way to flip ? There is most likely some git
magic
that can we do.


The new git workflow and the transition process need to be part of
a
proposal that we get consensus on.

getting there :)

-seb


Also, I'm struggling to understand the benefit of cherry-pick. If
you
completely squash history, you lose a tremendous amount of
context,
which I
use extensively to figure out why a bug is the way it is. Only
knowing
that
the branch was merged at a given point in time doesn't give any
context.
Seeing the individual commit history of the branch helps to
preserve
the
rationale for why the code was written the way it was. In theory
if
every
change starts out as a branch (feature, hotfix, release), then
why not
just
merge the branch once it is in a good and acceptable state?

I also agree with Mike that this will have to be a transition over
time. It
will take some time to clean up master to the point where it can
be
considered a solid stable branch. Possibly as part of the 4.5
release.


On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
runseb@gmail.com<ma...@gmail.com>

wrote:


On Jul 23, 2014, at 11:38 AM, daan Hoogland <
daan.hoogland@gmail.com>
wrote:

Sebastien,

It seems we can do what you are calling for is creating a branch
called 'release'. We can merge back into that branch from 4.4,
master,
4.3. I would like to see people that want a feature or bug fix
in a
branch make a fork of that branch and when that fork is working
do a
cherry-pick. The -forward concept is now used for that but it is
broken because more then for one piece of work there are
commits on
it. This caused me conflicts during the release. Especially
painfull
as not all was intended to get into the release. We can create
this
'release' branch now on the basis of 4.4 and start pulling in
changes.

Yes, that's what I am thinking about too, so +1

Our master would become the -develop- in gitflow terms
The release branch you mention would become the -master- in
gitflow
terms

If we start now, indeed we can create 'release' from 4.4 release
tag
(voted and shipped).

That means that to create 4.5 we will need to merge features
back into
'release'. it might be messy because some of those features are
already in
our current master.

But all of this will keep 'release' clean (we can keep track of
bugs
and
features that are in it in CHANGES file etc..)


There is a question of control. Do we allow all committers to
manage
the release? I am for that but can imagine not everybody is.


At first I would say that only the RM can commit to 'release'.
As we
get
the CI in place  we could relax this and allow commits that pass
the
CI to
get into 'release', but right now I would vote for a tighter
control
of
'release'.

rule number 1 will be: you are going to do something to the
code, you
start by creating a branch.

right?

On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
runseb@gmail.com>
wrote:

On Jul 23, 2014, at 11:19 AM, Sam Schmit <
sam.schmit@appcore.com>
wrote:

Hey everyone,

I've been a developer for a handful of years and have had my
share
of
experience with different version control systems.  I've used
(for
better
or worse) Git, Perforce, Rational ClearCast, and SVN.

Each of these solutions offers their own unique set of
features,
strengths
and weaknesses.  As there are so many systems that are good at
specific
things, it seems best to use the features that the chosen
system is
best at.

Git is great at branching, merging and using that structure to
maintain and
control how changes get into the primary branches.  Git tools
even
make
this easy by integrating directly into the "Gitflow" to make
branching
and
merging that much easier.  It would seem counter-intuitive to
NOT
make
use
of these built-in capabilities.

In addition to that, I know that the current method of change
management is
incredibly frustrating to work with, and works directly
against the
way a
typical Git user would expect it to be structured.  I should
NEVER
have
problem compiling and running something on master.  I should
not
have
problems building anything on a release branch.  A
feature/bugfix
branch is
where things can be, and often are, broken or unstable.
There have
been
many times working in Cloudstack where I've had to search for
a
stable
revision on master, and that's just plain wrong.

I do realize that having this many developers working on so
many
features
and bugfixes will result in a large number of branches.  I
don't
believe
this is a good argument against using a branching method,
though -
I
believe that the current system is even more confusing and
difficult
to use.

I could pontificate on change management quite a bit more,
but my
opinion
in summary would basically be:  use Git the way it was meant
to be
used,
and things will be better.  Just my two cents.

Sam



Sam, I think we are in agreement (at least with folks who
responded
to
this thread).
Or maybe I am not reading your mail right and you don't agree
with
Leo ?

My own take and reason for calling for a change we are
currently
doing
things is mostly due to the way we release.

I would like to see a stable master (and I think we are in
agreement
with that).
That means that development should not happen on master and
that
every
commit that lands on master should be shippable.

I personally have no issues with cherry-picking. So I would be
fine
cherry picking from a hot-fix branch into master, to fix a bug.
The end result is that the next commit on master would still
mean
master is shippable/releasable.

If we agree with this basic concept. The question becomes how
do we
get
there, considering that master is now full of dev work and
potential
bug.
The only releasable product we have are on the 4.3, 4.4 and
previous
release branches.

Ideally, I would like to see master becomes 4.4. And work our
way
back,
merging the new features that are already in master into the new
master
(based on 4.4).
This could be quite complicated but we need to do it (or
something
like
it).

To move forward, we should make a proposal to the list and
call for
a
vote.

Any takers to start a wiki page proposing a new git process
and how
we
could move to it (transition path) ?


-Sebastien



On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
LSimons@schubergphilis.com>
wrote:

Hey folks,

With 4.4.0 tagged, is now an opportune time to go and
implement
this?

I would enthousiastically +1 and get crackin', but I’m not a
committer so
its not that practical for me to volunteer!

I wanted to point out atlassian’s description of gitflow

https://www.atlassian.com/git/workflows#!workflow-gitflow

which might be easier to read.

Similarly, the git-flow scripts that help out with
implementing
this
stuff

https://github.com/nvie/gitflow

they also describe the relationship between gitflow and
dealing
with
multiple remotes

https://www.atlassian.com/git/workflows#!pull-request

Finally note atlassian’s free sourcetree GUI has built-in
support
for
git-flow

http://www.sourcetreeapp.com/

Because cloudstack currently is full of rebasing and
squashing and
cherry-picking, you get very little benefit from a tree
visualization
tool
(like this or gitk or ...) right now, but it would be
*great* to
have
going
forward.


cheers,


Leo

On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
runseb@gmail.com

wrote:

I would like to re-start this discussion.

Rajani made some good points and someone mentioned Gitflow:

http://nvie.com/posts/a-successful-git-branching-model/

Thinking about our release procedure, we clearly need more
tests
and
a
CI. However it looks like this is going to take some time.

In the meantime I think there is nothing preventing us from
agreeing
to
'git practices', we don't need tests or new infra, we just
need to
agree on
the git workflow.

Right now Master is really a development branch, we should
make
it a
stable branch for production with very few commits.
This does not mean that we would release less, in contrary
this
would
ensure that a commit to master means it's a production
release.

In addition gitflow [1] does not do cherry-picks (gets back
to
Rajani's
point) everything is based on merges.

I am of the opinion that git flow provides a nice process.
It
basically
freezes master. Development happens in a 'develop' branch,
releases
branches are branched off of that and merged into master and
back
into
develop….etc

Please read [1] it's a good read.

And let's discuss,

[1] http://nvie.com/posts/a-successful-git-branching-model/

-Sebastien

On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
Rajani.Karuturi@citrix.com>
wrote:

There is also the problem of cherry-picking.
As a contributor, I always endup creating multiple patches
for
each
branch as they don’t cleanly apply on the upward branches.
which
means
distinct commits for each branch and I don’t easily know
which all
branches
my commit exists unless I do grep.
if we follow merging strategy properly, apart from the
first
merge
of
the branch, everything else on top of it should be a painless
merge.



~Rajani



On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
wrote:

I think many of the bullet points are what we are
currently
doing
(guidelines for commit comments, feature branches need to
stay
in
sync
with
master, no back-merging). I also think that much of what
we do
now
is
done
the way it is simply because there *are* vast changes
between
versions.
Classes are getting shuffled around and changed all the
time.
If
its
feasible to merge branch fixes to master, that's fine,
but some
quick
tests
seem to indicate that this will be messy getting started.

That leaves us with how we do releases. I'm fine with
having
single
branches for major releases(4.3) and tagging the commits
where
each
incremental release (4.3.x) is done. I'm trying to
remember
why we
went
with the -forward, I'm sure it's in the mailing list
somewhere, but
one of
the nice things it provides is the ability for the release
manager
to
control what changes are made during code freeze while
giving
people a
place to stage fixes (though admittedly this is not always
followed).
Without -forward, would the flow be for each dev to have
their
own
repo and
issue pull requests for bugfixes?


On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
Rajani.Karuturi@citrix.com>
wrote:

Any other suggestions/objections/comments??
Can we discuss this in detail and agree to a process??


~Rajani



On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
Rajani.Karuturi@citrix.com>
wrote:

Yes as mike said, if its a one-off case we can do a
empty
merge(merge -s
ours) for it and git will assume its merged but will not
bring in
any
changes.

If the branches diverged a lot, for example after a
major
rewrite, we
could stop merging to that branch and above and make the
fix
manually.


~Rajani



On 30-May-2014, at 11:26 pm, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

Yep, that's what I was referring to in that a
particular fix
for an
old
release may not apply to newer versions. That does
happen.

We used to mark those as "don't need to merge to
branch x"
in
SVN
and
then
you handed it however made sense on the applicable
branch(es).


On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
Stephen.Turner@citrix.com>
wrote:

What happens if a fix isn't relevant for newer
versions, or
has to
be
rewritten for newer versions because the code has
changed?
Don't
the
branches diverge and you end up cherry-picking after
that?

--
Stephen Turner


-----Original Message-----
From: Mike Tutkowski [mailto:
mike.tutkowski@solidfire.com]
Sent: 30 May 2014 18:48
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] git workflow

I think this flow is something we should seriously
consider.

I find cherry picking from branch to branch to be
error
prone
in
that
it's
easy for someone to forget to cherry pick to all
applicable
branches
and
you don't have any easy way to see the cherry picks
are
related.

When I worked at HP, we had automated tools check to
see
if you
checked a
fix into a prior release, but not later releases. In
such a
situation,
you
either 1) forgot to perform the check-in or 2) the
check-in
was no
longer
applicable in the later release(s), so you needed to
mark
it as
un-necessary (SVN supported this ability...not sure
about
Git).


On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
Rajani.Karuturi@citrix.com> wrote:

Hi all,



Our current git workflow is confusing with the
*forward
branches
and
cherry-picking. Its hard to track on what all
releases the
commit
has
gone into unless I do some git log greping. Also, as
a
contributor, I
endup creating patches for each branch as it doesn’t
cleanly
apply on
different branches.



I think we should have some guidelines. Here is what
I
propose.



1.  There should be branch for every major
release(ex:
4.3.x,
4.4.x,
5.0.x,5.1.x) and the minor releases should be tagged
accordingly
on
the respective branches.
2.  The branch naming convention is to be followed.
Many
branches
with 4.3, 4.3.0, 4.3.1 etc. is confusing
3.  Cherry-picking should be avoided. In git, when we
cherry-pick,
we have two physically distinct commits for the same
change or
fix and
is difficult to track unless you do cherry-pick -x
4.  There should always be a continous flow from
release
branches
to
master. This doesn’t mean cherry-picking. They
should be
merged(either
ff or no-ff) which retains the commit ids and easily
trackable
with
git branch --contains
*   Every bug fix should always flow from minimal
release
uptill
master. A bug isnt fixed until the fix reaches
master.
*   For ex. A bug 4.2.1 should be committed to
4.2.x->4.3.x->4.4.x->master
*   If someone forgets to do the merge, the next
time a
new
commit
is
done this will also get merged.
5.  There should always be a continuous flow from
master
to
feature
branches. Meaning all feature branch owners should
proactively
take
any new commits from master by doing a merge from
master
6.  The commits from feature branch will make to
master on
code
complete through a merge.
7.  There should never be a merge from master to
release
branches
8.  Every commit in LTS branch(targetted to any minor
release)
should have atleast bug id and correct author
information
*   Cassandra's template: patch by <author>;
reviewed by
<committer>
for CASSANDRA-<ticket>
9.  Once the release branch is created(after code
freeze),
any bug
in jira can be marked with fix version current
release(4.4)
only
on
RM's approval and only they can go to the release
branch.
This
can be
done through jira and with certain rules.(may be
using
jira
vote?)
this would save the cherry-picking time and another
branch
maintenance.



Please add your thoughts/suggestions/comments.



Ref:


http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
https://www.youtube.com/watch?v=AJ-CpGsCpM0

~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
*™*




--
*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




--


*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.





--
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>*™*




--
Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

24. juli 2014 08:39 skrev "Rajani Karuturi" <Ra...@citrix.com>
følgende:
>
>
> Hi Daan,
> here is what i propose:
>
> 1. rename 'master' to 'develop’
> 2. branch a new 'master' from '4.4’
> 3. branch 'RELEASE-4.5' from the develop
> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>
> RELEASE-4.6 branch should be off develop as all the feature branches
would be merged there before freeze for 4.6 and would be merged to master
when the release is voted.
>
> The other question I have is in the step:4. how are we going to manage
fixes to 4.5 post branch cut?  ( assuming no features as the freeze is done)

Sub releases, ie. 4.4.1,  is generally just hotfixes / bugfixes, yes? In
that case you can branch it off 'master' and merge back to master as a new
release after voting, and merge to develop if the fix is applicable there.

Erik
>
> ~Rajani
>
>
>
> On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com>
wrote:
>
> > Mike, Rajani,
> >
> > Sebastien's point was that the current 4.4 is the closest we have to a
> > releasable branch. I don't mind enting on master but it will require
> > more fixing. In general all of this will require some RM work of all
> > committers. Please ammend my little proposal if you will.
> >
> > On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
> > <Ra...@citrix.com> wrote:
> >> I agree with mike. I think we should start 4.5 from where master is now
> >> Also create a develop branch from master and continue future work for
4.6 there.
> >>
> >> I am not clear on how the release branches are going to be maintained.
> >> Are we saying we would create 4.5-RELEASE branch which is essentially
same as our current -FORWARD branch and continue cherry-picking?
> >>
> >> I would prefer merges to cherry-picks.
> >> Also, I think we should allow committers to commit to the RELEASE
branch after discussing about it on dev@ and have RM closely monitor them.
> >> Any commit intended for 4.5 RELEASE should be checked in after
discussion in the 4.5 Release branch and then merged to develop branch.
> >>
> >>
> >> ~Rajani
> >>
> >>
> >>
> >> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:
> >>
> >>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
left off
> >>> and then merge features from develop into 4.5.
> >>>
> >>> Why don't we instead start 4.5 where master is now with the
assumption that
> >>> since we are past Feature Freeze for 4.5 that master is stable enough?
> >>>
> >>>
> >>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
daan.hoogland@gmail.com>
> >>> wrote:
> >>>
> >>>> so to start formulate a proposal:
> >>>>
> >>>> all work shall be done in a new branch (it is advisable to prefix
your
> >>>> branches with your id)
> >>>> when working, features will be cherry-picked/merged into the release
> >>>> branch they are for and next into master.
> >>>> hotfixes will be done in <branchname>-hotfixes
> >>>>
> >>>> as transition we will
> >>>>
> >>>> rename 'master' to 'develop'
> >>>> branch a new 'master' from '4.4'
> >>>> branch '4.5' from the new 'master'
> >>>> merge any features from the new 'develop' to '4.5' and 'master'
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <runseb@gmail.com
>
> >>>> wrote:
> >>>>>
> >>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <ru...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> Let me ask the question, why have master be develop and a release
> >>>> branch be
> >>>>>>> "master"? If we are going to follow gitflow, why not just stick
with
> >>>> the
> >>>>>>> norm? If master is the development branch, it might not be
stable. I
> >>>> think
> >>>>>>> the goal here is that we have an obvious stable branch. Anyone
could
> >>>> come
> >>>>>>> check out master and have the latest useable.
> >>>>>>
> >>>>>> I am in favor of following the norm, so ideally master should be
our
> >>>> stable branch (agreed).
> >>>>>>
> >>>>>> The issue is with the transition.
> >>>>>>
> >>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
ideally
> >>>> we could start a stable branch of this tag and build up bug fix
releases
> >>>> all the way to 4.5 from there.
> >>>>>>
> >>>>>> But all features for 4.5 are already in master.
> >>>>>>
> >>>>>> So if we create a 'develop' branch of master and stabilize 'master'
> >>>> then develop is now started from a stable tag (4.4.0).
> >>>>>>
> >>>>>
> >>>>> *not* started from a stable tag, and merges will be tricky, no ?
> >>>>>
> >>>>>> So what's the best way to flip ? There is most likely some git
magic
> >>>> that can we do.
> >>>>>>
> >>>>>>
> >>>>>> The new git workflow and the transition process need to be part of
a
> >>>> proposal that we get consensus on.
> >>>>>>
> >>>>>> getting there :)
> >>>>>>
> >>>>>> -seb
> >>>>>>
> >>>>>>>
> >>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If
you
> >>>>>>> completely squash history, you lose a tremendous amount of
context,
> >>>> which I
> >>>>>>> use extensively to figure out why a bug is the way it is. Only
knowing
> >>>> that
> >>>>>>> the branch was merged at a given point in time doesn't give any
> >>>> context.
> >>>>>>> Seeing the individual commit history of the branch helps to
preserve
> >>>> the
> >>>>>>> rationale for why the code was written the way it was. In theory
if
> >>>> every
> >>>>>>> change starts out as a branch (feature, hotfix, release), then
why not
> >>>> just
> >>>>>>> merge the branch once it is in a good and acceptable state?
> >>>>>>>
> >>>>>>> I also agree with Mike that this will have to be a transition over
> >>>> time. It
> >>>>>>> will take some time to clean up master to the point where it can
be
> >>>>>>> considered a solid stable branch. Possibly as part of the 4.5
release.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
runseb@gmail.com
> >>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <
daan.hoogland@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Sebastien,
> >>>>>>>>>
> >>>>>>>>> It seems we can do what you are calling for is creating a branch
> >>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
> >>>> master,
> >>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
in a
> >>>>>>>>> branch make a fork of that branch and when that fork is working
do a
> >>>>>>>>> cherry-pick. The -forward concept is now used for that but it is
> >>>>>>>>> broken because more then for one piece of work there are
commits on
> >>>>>>>>> it. This caused me conflicts during the release. Especially
painfull
> >>>>>>>>> as not all was intended to get into the release. We can create
this
> >>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
> >>>> changes.
> >>>>>>>>
> >>>>>>>> Yes, that's what I am thinking about too, so +1
> >>>>>>>>
> >>>>>>>> Our master would become the -develop- in gitflow terms
> >>>>>>>> The release branch you mention would become the -master- in
gitflow
> >>>> terms
> >>>>>>>>
> >>>>>>>> If we start now, indeed we can create 'release' from 4.4 release
tag
> >>>>>>>> (voted and shipped).
> >>>>>>>>
> >>>>>>>> That means that to create 4.5 we will need to merge features
back into
> >>>>>>>> 'release'. it might be messy because some of those features are
> >>>> already in
> >>>>>>>> our current master.
> >>>>>>>>
> >>>>>>>> But all of this will keep 'release' clean (we can keep track of
bugs
> >>>> and
> >>>>>>>> features that are in it in CHANGES file etc..)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> There is a question of control. Do we allow all committers to
manage
> >>>>>>>>> the release? I am for that but can imagine not everybody is.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> At first I would say that only the RM can commit to 'release'.
As we
> >>>> get
> >>>>>>>> the CI in place  we could relax this and allow commits that pass
the
> >>>> CI to
> >>>>>>>> get into 'release', but right now I would vote for a tighter
control
> >>>> of
> >>>>>>>> 'release'.
> >>>>>>>>
> >>>>>>>>> rule number 1 will be: you are going to do something to the
code, you
> >>>>>>>>> start by creating a branch.
> >>>>>>>>>
> >>>>>>>>> right?
> >>>>>>>>>
> >>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
> >>>> runseb@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <
sam.schmit@appcore.com>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hey everyone,
> >>>>>>>>>>>
> >>>>>>>>>>> I've been a developer for a handful of years and have had my
share
> >>>> of
> >>>>>>>>>>> experience with different version control systems.  I've used
(for
> >>>>>>>> better
> >>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>>>>>>>>>
> >>>>>>>>>>> Each of these solutions offers their own unique set of
features,
> >>>>>>>> strengths
> >>>>>>>>>>> and weaknesses.  As there are so many systems that are good at
> >>>> specific
> >>>>>>>>>>> things, it seems best to use the features that the chosen
system is
> >>>>>>>> best at.
> >>>>>>>>>>>
> >>>>>>>>>>> Git is great at branching, merging and using that structure to
> >>>>>>>> maintain and
> >>>>>>>>>>> control how changes get into the primary branches.  Git tools
even
> >>>> make
> >>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
> >>>> branching
> >>>>>>>> and
> >>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to
NOT
> >>>> make
> >>>>>>>> use
> >>>>>>>>>>> of these built-in capabilities.
> >>>>>>>>>>>
> >>>>>>>>>>> In addition to that, I know that the current method of change
> >>>>>>>> management is
> >>>>>>>>>>> incredibly frustrating to work with, and works directly
against the
> >>>>>>>> way a
> >>>>>>>>>>> typical Git user would expect it to be structured.  I should
NEVER
> >>>> have
> >>>>>>>>>>> problem compiling and running something on master.  I should
not
> >>>> have
> >>>>>>>>>>> problems building anything on a release branch.  A
feature/bugfix
> >>>>>>>> branch is
> >>>>>>>>>>> where things can be, and often are, broken or unstable.
 There have
> >>>>>>>> been
> >>>>>>>>>>> many times working in Cloudstack where I've had to search for
a
> >>>> stable
> >>>>>>>>>>> revision on master, and that's just plain wrong.
> >>>>>>>>>>>
> >>>>>>>>>>> I do realize that having this many developers working on so
many
> >>>>>>>> features
> >>>>>>>>>>> and bugfixes will result in a large number of branches.  I
don't
> >>>>>>>> believe
> >>>>>>>>>>> this is a good argument against using a branching method,
though -
> >>>> I
> >>>>>>>>>>> believe that the current system is even more confusing and
> >>>> difficult
> >>>>>>>> to use.
> >>>>>>>>>>>
> >>>>>>>>>>> I could pontificate on change management quite a bit more,
but my
> >>>>>>>> opinion
> >>>>>>>>>>> in summary would basically be:  use Git the way it was meant
to be
> >>>>>>>> used,
> >>>>>>>>>>> and things will be better.  Just my two cents.
> >>>>>>>>>>>
> >>>>>>>>>>> Sam
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Sam, I think we are in agreement (at least with folks who
responded
> >>>> to
> >>>>>>>> this thread).
> >>>>>>>>>> Or maybe I am not reading your mail right and you don't agree
with
> >>>> Leo ?
> >>>>>>>>>>
> >>>>>>>>>> My own take and reason for calling for a change we are
currently
> >>>> doing
> >>>>>>>> things is mostly due to the way we release.
> >>>>>>>>>>
> >>>>>>>>>> I would like to see a stable master (and I think we are in
agreement
> >>>>>>>> with that).
> >>>>>>>>>> That means that development should not happen on master and
that
> >>>> every
> >>>>>>>> commit that lands on master should be shippable.
> >>>>>>>>>>
> >>>>>>>>>> I personally have no issues with cherry-picking. So I would be
fine
> >>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
> >>>>>>>>>> The end result is that the next commit on master would still
mean
> >>>>>>>> master is shippable/releasable.
> >>>>>>>>>>
> >>>>>>>>>> If we agree with this basic concept. The question becomes how
do we
> >>>> get
> >>>>>>>> there, considering that master is now full of dev work and
potential
> >>>> bug.
> >>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
previous
> >>>>>>>> release branches.
> >>>>>>>>>>
> >>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our
way
> >>>> back,
> >>>>>>>> merging the new features that are already in master into the new
> >>>> master
> >>>>>>>> (based on 4.4).
> >>>>>>>>>> This could be quite complicated but we need to do it (or
something
> >>>> like
> >>>>>>>> it).
> >>>>>>>>>>
> >>>>>>>>>> To move forward, we should make a proposal to the list and
call for
> >>>> a
> >>>>>>>> vote.
> >>>>>>>>>>
> >>>>>>>>>> Any takers to start a wiki page proposing a new git process
and how
> >>>> we
> >>>>>>>> could move to it (transition path) ?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> -Sebastien
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
> >>>>>>>> LSimons@schubergphilis.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hey folks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
implement
> >>>> this?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
> >>>>>>>> committer so
> >>>>>>>>>>>> its not that practical for me to volunteer!
> >>>>>>>>>>>>
> >>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
> >>>>>>>>>>>>
> >>>>>>>>>>>> which might be easier to read.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Similarly, the git-flow scripts that help out with
implementing
> >>>> this
> >>>>>>>> stuff
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://github.com/nvie/gitflow
> >>>>>>>>>>>>
> >>>>>>>>>>>> they also describe the relationship between gitflow and
dealing
> >>>> with
> >>>>>>>>>>>> multiple remotes
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
> >>>>>>>>>>>>
> >>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
support
> >>>> for
> >>>>>>>>>>>> git-flow
> >>>>>>>>>>>>
> >>>>>>>>>>>> http://www.sourcetreeapp.com/
> >>>>>>>>>>>>
> >>>>>>>>>>>> Because cloudstack currently is full of rebasing and
squashing and
> >>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
> >>>> visualization
> >>>>>>>> tool
> >>>>>>>>>>>> (like this or gitk or ...) right now, but it would be
*great* to
> >>>> have
> >>>>>>>> going
> >>>>>>>>>>>> forward.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> cheers,
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Leo
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
runseb@gmail.com
> >>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I would like to re-start this discussion.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thinking about our release procedure, we clearly need more
tests
> >>>> and
> >>>>>>>> a
> >>>>>>>>>>>> CI. However it looks like this is going to take some time.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
> >>>> agreeing
> >>>>>>>> to
> >>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just
need to
> >>>>>>>> agree on
> >>>>>>>>>>>> the git workflow.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Right now Master is really a development branch, we should
make
> >>>> it a
> >>>>>>>>>>>> stable branch for production with very few commits.
> >>>>>>>>>>>>> This does not mean that we would release less, in contrary
this
> >>>> would
> >>>>>>>>>>>> ensure that a commit to master means it's a production
release.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back
to
> >>>>>>>> Rajani's
> >>>>>>>>>>>> point) everything is based on merges.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I am of the opinion that git flow provides a nice process.
It
> >>>>>>>> basically
> >>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
> >>>> releases
> >>>>>>>>>>>> branches are branched off of that and merged into master and
back
> >>>> into
> >>>>>>>>>>>> develop….etc
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Please read [1] it's a good read.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> And let's discuss,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Sebastien
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
> >>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> There is also the problem of cherry-picking.
> >>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches
for
> >>>> each
> >>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches.
which
> >>>> means
> >>>>>>>>>>>> distinct commits for each branch and I don’t easily know
which all
> >>>>>>>> branches
> >>>>>>>>>>>> my commit exists unless I do grep.
> >>>>>>>>>>>>>> if we follow merging strategy properly, apart from the
first
> >>>> merge
> >>>>>>>> of
> >>>>>>>>>>>> the branch, everything else on top of it should be a painless
> >>>> merge.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
> >>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I think many of the bullet points are what we are
currently
> >>>> doing
> >>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to
stay
> >>>> in
> >>>>>>>> sync
> >>>>>>>>>>>> with
> >>>>>>>>>>>>>>> master, no back-merging). I also think that much of what
we do
> >>>> now
> >>>>>>>> is
> >>>>>>>>>>>> done
> >>>>>>>>>>>>>>> the way it is simply because there *are* vast changes
between
> >>>>>>>> versions.
> >>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the
time.
> >>>> If
> >>>>>>>> its
> >>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine,
but some
> >>>>>>>> quick
> >>>>>>>>>>>> tests
> >>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with
having
> >>>> single
> >>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits
where
> >>>> each
> >>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to
remember
> >>>> why we
> >>>>>>>> went
> >>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
> >>>> somewhere, but
> >>>>>>>>>>>> one of
> >>>>>>>>>>>>>>> the nice things it provides is the ability for the release
> >>>> manager
> >>>>>>>> to
> >>>>>>>>>>>>>>> control what changes are made during code freeze while
giving
> >>>>>>>> people a
> >>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not always
> >>>>>>>> followed).
> >>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have
their
> >>>> own
> >>>>>>>>>>>> repo and
> >>>>>>>>>>>>>>> issue pull requests for bugfixes?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> >>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
> >>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> >>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a
empty
> >>>>>>>>>>>> merge(merge -s
> >>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
> >>>> bring in
> >>>>>>>> any
> >>>>>>>>>>>>>>>> changes.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a
major
> >>>>>>>> rewrite, we
> >>>>>>>>>>>>>>>> could stop merging to that branch and above and make the
fix
> >>>>>>>> manually.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a
particular fix
> >>>>>>>> for an
> >>>>>>>>>>>> old
> >>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does
happen.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to
branch x"
> >>>> in
> >>>>>>>> SVN
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
> >>>> branch(es).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
versions, or
> >>>>>>>> has to
> >>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
changed?
> >>>>>>>> Don't
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after
that?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> Stephen Turner
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
mike.tutkowski@solidfire.com]
> >>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
> >>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
> >>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
> >>>> consider.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be
error
> >>>> prone
> >>>>>>>> in
> >>>>>>>>>>>> that
> >>>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
applicable
> >>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks
are
> >>>>>>>> related.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to
see
> >>>> if you
> >>>>>>>>>>>>>>>> checked a
> >>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In
such a
> >>>>>>>>>>>> situation,
> >>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
check-in
> >>>>>>>> was no
> >>>>>>>>>>>>>>>> longer
> >>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to
mark
> >>>> it as
> >>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure
about
> >>>> Git).
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the
*forward
> >>>>>>>> branches
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all
releases the
> >>>>>>>> commit
> >>>>>>>>>>>> has
> >>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as
a
> >>>>>>>>>>>> contributor, I
> >>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
> >>>> cleanly
> >>>>>>>>>>>> apply on
> >>>>>>>>>>>>>>>>>>>> different branches.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is what
I
> >>>>>>>> propose.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major
release(ex:
> >>>> 4.3.x,
> >>>>>>>>>>>> 4.4.x,
> >>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
> >>>>>>>> accordingly
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>> the respective branches.
> >>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed.
Many
> >>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
> >>>>>>>> cherry-pick,
> >>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
> >>>> change or
> >>>>>>>>>>>> fix and
> >>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
release
> >>>>>>>> branches
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They
should be
> >>>>>>>>>>>> merged(either
> >>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
> >>>> trackable
> >>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>> git branch --contains
> >>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
release
> >>>>>>>> uptill
> >>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches
master.
> >>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> >>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next
time a
> >>>> new
> >>>>>>>> commit
> >>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>> done this will also get merged.
> >>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
master
> >>>> to
> >>>>>>>>>>>> feature
> >>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
> >>>> proactively
> >>>>>>>>>>>> take
> >>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
master
> >>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
master on
> >>>>>>>> code
> >>>>>>>>>>>>>>>>>>>> complete through a merge.
> >>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
release
> >>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor
> >>>> release)
> >>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
information
> >>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>;
reviewed by
> >>>>>>>>>>>>>>>> <committer>
> >>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
> >>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
freeze),
> >>>>>>>> any bug
> >>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
> >>>> release(4.4)
> >>>>>>>> only
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
branch.
> >>>>>>>> This
> >>>>>>>>>>>> can be
> >>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be
using
> >>>> jira
> >>>>>>>> vote?)
> >>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another
branch
> >>>>>>>>>>>>>>>> maintenance.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Ref:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ~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
>*™*
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> *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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>>
> >>>>>>> *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.
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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>*™*
> >>
> >
> >
> >
> > --
> > Daan
>

Re: [DISCUSS][PROPOSAL] git workflow

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

Hi Daan,
here is what i propose:

1. rename 'master' to 'develop’
2. branch a new 'master' from '4.4’
3. branch 'RELEASE-4.5' from the develop
4. merge 'RELEASE-4.5' to master once the release voting is done.

RELEASE-4.6 branch should be off develop as all the feature branches would be merged there before freeze for 4.6 and would be merged to master when the release is voted.

The other question I have is in the step:4. how are we going to manage fixes to 4.5 post branch cut?  ( assuming no features as the freeze is done)

~Rajani



On 24-Jul-2014, at 11:52 am, Daan Hoogland <da...@gmail.com> wrote:

> Mike, Rajani,
> 
> Sebastien's point was that the current 4.4 is the closest we have to a
> releasable branch. I don't mind enting on master but it will require
> more fixing. In general all of this will require some RM work of all
> committers. Please ammend my little proposal if you will.
> 
> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
> <Ra...@citrix.com> wrote:
>> I agree with mike. I think we should start 4.5 from where master is now
>> Also create a develop branch from master and continue future work for 4.6 there.
>> 
>> I am not clear on how the release branches are going to be maintained.
>> Are we saying we would create 4.5-RELEASE branch which is essentially same as our current -FORWARD branch and continue cherry-picking?
>> 
>> I would prefer merges to cherry-picks.
>> Also, I think we should allow committers to commit to the RELEASE branch after discussing about it on dev@ and have RM closely monitor them.
>> Any commit intended for 4.5 RELEASE should be checked in after discussion in the 4.5 Release branch and then merged to develop branch.
>> 
>> 
>> ~Rajani
>> 
>> 
>> 
>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <mi...@solidfire.com> wrote:
>> 
>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4 left off
>>> and then merge features from develop into 4.5.
>>> 
>>> Why don't we instead start 4.5 where master is now with the assumption that
>>> since we are past Feature Freeze for 4.5 that master is stable enough?
>>> 
>>> 
>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <da...@gmail.com>
>>> wrote:
>>> 
>>>> so to start formulate a proposal:
>>>> 
>>>> all work shall be done in a new branch (it is advisable to prefix your
>>>> branches with your id)
>>>> when working, features will be cherry-picked/merged into the release
>>>> branch they are for and next into master.
>>>> hotfixes will be done in <branchname>-hotfixes
>>>> 
>>>> as transition we will
>>>> 
>>>> rename 'master' to 'develop'
>>>> branch a new 'master' from '4.4'
>>>> branch '4.5' from the new 'master'
>>>> merge any features from the new 'develop' to '4.5' and 'master'
>>>> 
>>>> 
>>>> 
>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <ru...@gmail.com>
>>>> wrote:
>>>>> 
>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <ru...@gmail.com>
>>>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com>
>>>> wrote:
>>>>>> 
>>>>>>> Let me ask the question, why have master be develop and a release
>>>> branch be
>>>>>>> "master"? If we are going to follow gitflow, why not just stick with
>>>> the
>>>>>>> norm? If master is the development branch, it might not be stable. I
>>>> think
>>>>>>> the goal here is that we have an obvious stable branch. Anyone could
>>>> come
>>>>>>> check out master and have the latest useable.
>>>>>> 
>>>>>> I am in favor of following the norm, so ideally master should be our
>>>> stable branch (agreed).
>>>>>> 
>>>>>> The issue is with the transition.
>>>>>> 
>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally
>>>> we could start a stable branch of this tag and build up bug fix releases
>>>> all the way to 4.5 from there.
>>>>>> 
>>>>>> But all features for 4.5 are already in master.
>>>>>> 
>>>>>> So if we create a 'develop' branch of master and stabilize 'master'
>>>> then develop is now started from a stable tag (4.4.0).
>>>>>> 
>>>>> 
>>>>> *not* started from a stable tag, and merges will be tricky, no ?
>>>>> 
>>>>>> So what's the best way to flip ? There is most likely some git magic
>>>> that can we do.
>>>>>> 
>>>>>> 
>>>>>> The new git workflow and the transition process need to be part of a
>>>> proposal that we get consensus on.
>>>>>> 
>>>>>> getting there :)
>>>>>> 
>>>>>> -seb
>>>>>> 
>>>>>>> 
>>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If you
>>>>>>> completely squash history, you lose a tremendous amount of context,
>>>> which I
>>>>>>> use extensively to figure out why a bug is the way it is. Only knowing
>>>> that
>>>>>>> the branch was merged at a given point in time doesn't give any
>>>> context.
>>>>>>> Seeing the individual commit history of the branch helps to preserve
>>>> the
>>>>>>> rationale for why the code was written the way it was. In theory if
>>>> every
>>>>>>> change starts out as a branch (feature, hotfix, release), then why not
>>>> just
>>>>>>> merge the branch once it is in a good and acceptable state?
>>>>>>> 
>>>>>>> I also agree with Mike that this will have to be a transition over
>>>> time. It
>>>>>>> will take some time to clean up master to the point where it can be
>>>>>>> considered a solid stable branch. Possibly as part of the 4.5 release.
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <runseb@gmail.com
>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Sebastien,
>>>>>>>>> 
>>>>>>>>> It seems we can do what you are calling for is creating a branch
>>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
>>>> master,
>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix in a
>>>>>>>>> branch make a fork of that branch and when that fork is working do a
>>>>>>>>> cherry-pick. The -forward concept is now used for that but it is
>>>>>>>>> broken because more then for one piece of work there are commits on
>>>>>>>>> it. This caused me conflicts during the release. Especially painfull
>>>>>>>>> as not all was intended to get into the release. We can create this
>>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
>>>> changes.
>>>>>>>> 
>>>>>>>> Yes, that's what I am thinking about too, so +1
>>>>>>>> 
>>>>>>>> Our master would become the -develop- in gitflow terms
>>>>>>>> The release branch you mention would become the -master- in gitflow
>>>> terms
>>>>>>>> 
>>>>>>>> If we start now, indeed we can create 'release' from 4.4 release tag
>>>>>>>> (voted and shipped).
>>>>>>>> 
>>>>>>>> That means that to create 4.5 we will need to merge features back into
>>>>>>>> 'release'. it might be messy because some of those features are
>>>> already in
>>>>>>>> our current master.
>>>>>>>> 
>>>>>>>> But all of this will keep 'release' clean (we can keep track of bugs
>>>> and
>>>>>>>> features that are in it in CHANGES file etc..)
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> There is a question of control. Do we allow all committers to manage
>>>>>>>>> the release? I am for that but can imagine not everybody is.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> At first I would say that only the RM can commit to 'release'. As we
>>>> get
>>>>>>>> the CI in place  we could relax this and allow commits that pass the
>>>> CI to
>>>>>>>> get into 'release', but right now I would vote for a tighter control
>>>> of
>>>>>>>> 'release'.
>>>>>>>> 
>>>>>>>>> rule number 1 will be: you are going to do something to the code, you
>>>>>>>>> start by creating a branch.
>>>>>>>>> 
>>>>>>>>> right?
>>>>>>>>> 
>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
>>>> runseb@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hey everyone,
>>>>>>>>>>> 
>>>>>>>>>>> I've been a developer for a handful of years and have had my share
>>>> of
>>>>>>>>>>> experience with different version control systems.  I've used (for
>>>>>>>> better
>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>>>>>>>>>> 
>>>>>>>>>>> Each of these solutions offers their own unique set of features,
>>>>>>>> strengths
>>>>>>>>>>> and weaknesses.  As there are so many systems that are good at
>>>> specific
>>>>>>>>>>> things, it seems best to use the features that the chosen system is
>>>>>>>> best at.
>>>>>>>>>>> 
>>>>>>>>>>> Git is great at branching, merging and using that structure to
>>>>>>>> maintain and
>>>>>>>>>>> control how changes get into the primary branches.  Git tools even
>>>> make
>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
>>>> branching
>>>>>>>> and
>>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to NOT
>>>> make
>>>>>>>> use
>>>>>>>>>>> of these built-in capabilities.
>>>>>>>>>>> 
>>>>>>>>>>> In addition to that, I know that the current method of change
>>>>>>>> management is
>>>>>>>>>>> incredibly frustrating to work with, and works directly against the
>>>>>>>> way a
>>>>>>>>>>> typical Git user would expect it to be structured.  I should NEVER
>>>> have
>>>>>>>>>>> problem compiling and running something on master.  I should not
>>>> have
>>>>>>>>>>> problems building anything on a release branch.  A feature/bugfix
>>>>>>>> branch is
>>>>>>>>>>> where things can be, and often are, broken or unstable.  There have
>>>>>>>> been
>>>>>>>>>>> many times working in Cloudstack where I've had to search for a
>>>> stable
>>>>>>>>>>> revision on master, and that's just plain wrong.
>>>>>>>>>>> 
>>>>>>>>>>> I do realize that having this many developers working on so many
>>>>>>>> features
>>>>>>>>>>> and bugfixes will result in a large number of branches.  I don't
>>>>>>>> believe
>>>>>>>>>>> this is a good argument against using a branching method, though -
>>>> I
>>>>>>>>>>> believe that the current system is even more confusing and
>>>> difficult
>>>>>>>> to use.
>>>>>>>>>>> 
>>>>>>>>>>> I could pontificate on change management quite a bit more, but my
>>>>>>>> opinion
>>>>>>>>>>> in summary would basically be:  use Git the way it was meant to be
>>>>>>>> used,
>>>>>>>>>>> and things will be better.  Just my two cents.
>>>>>>>>>>> 
>>>>>>>>>>> Sam
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Sam, I think we are in agreement (at least with folks who responded
>>>> to
>>>>>>>> this thread).
>>>>>>>>>> Or maybe I am not reading your mail right and you don't agree with
>>>> Leo ?
>>>>>>>>>> 
>>>>>>>>>> My own take and reason for calling for a change we are currently
>>>> doing
>>>>>>>> things is mostly due to the way we release.
>>>>>>>>>> 
>>>>>>>>>> I would like to see a stable master (and I think we are in agreement
>>>>>>>> with that).
>>>>>>>>>> That means that development should not happen on master and that
>>>> every
>>>>>>>> commit that lands on master should be shippable.
>>>>>>>>>> 
>>>>>>>>>> I personally have no issues with cherry-picking. So I would be fine
>>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
>>>>>>>>>> The end result is that the next commit on master would still mean
>>>>>>>> master is shippable/releasable.
>>>>>>>>>> 
>>>>>>>>>> If we agree with this basic concept. The question becomes how do we
>>>> get
>>>>>>>> there, considering that master is now full of dev work and potential
>>>> bug.
>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and previous
>>>>>>>> release branches.
>>>>>>>>>> 
>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our way
>>>> back,
>>>>>>>> merging the new features that are already in master into the new
>>>> master
>>>>>>>> (based on 4.4).
>>>>>>>>>> This could be quite complicated but we need to do it (or something
>>>> like
>>>>>>>> it).
>>>>>>>>>> 
>>>>>>>>>> To move forward, we should make a proposal to the list and call for
>>>> a
>>>>>>>> vote.
>>>>>>>>>> 
>>>>>>>>>> Any takers to start a wiki page proposing a new git process and how
>>>> we
>>>>>>>> could move to it (transition path) ?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> -Sebastien
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>>>>>>>> LSimons@schubergphilis.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hey folks,
>>>>>>>>>>>> 
>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and implement
>>>> this?
>>>>>>>>>>>> 
>>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
>>>>>>>> committer so
>>>>>>>>>>>> its not that practical for me to volunteer!
>>>>>>>>>>>> 
>>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
>>>>>>>>>>>> 
>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>>>>>>>>>> 
>>>>>>>>>>>> which might be easier to read.
>>>>>>>>>>>> 
>>>>>>>>>>>> Similarly, the git-flow scripts that help out with implementing
>>>> this
>>>>>>>> stuff
>>>>>>>>>>>> 
>>>>>>>>>>>> https://github.com/nvie/gitflow
>>>>>>>>>>>> 
>>>>>>>>>>>> they also describe the relationship between gitflow and dealing
>>>> with
>>>>>>>>>>>> multiple remotes
>>>>>>>>>>>> 
>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>>>>>>>>>>>> 
>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in support
>>>> for
>>>>>>>>>>>> git-flow
>>>>>>>>>>>> 
>>>>>>>>>>>> http://www.sourcetreeapp.com/
>>>>>>>>>>>> 
>>>>>>>>>>>> Because cloudstack currently is full of rebasing and squashing and
>>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
>>>> visualization
>>>>>>>> tool
>>>>>>>>>>>> (like this or gitk or ...) right now, but it would be *great* to
>>>> have
>>>>>>>> going
>>>>>>>>>>>> forward.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> cheers,
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Leo
>>>>>>>>>>>> 
>>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <runseb@gmail.com
>>>>> 
>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I would like to re-start this discussion.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thinking about our release procedure, we clearly need more tests
>>>> and
>>>>>>>> a
>>>>>>>>>>>> CI. However it looks like this is going to take some time.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
>>>> agreeing
>>>>>>>> to
>>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just need to
>>>>>>>> agree on
>>>>>>>>>>>> the git workflow.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Right now Master is really a development branch, we should make
>>>> it a
>>>>>>>>>>>> stable branch for production with very few commits.
>>>>>>>>>>>>> This does not mean that we would release less, in contrary this
>>>> would
>>>>>>>>>>>> ensure that a commit to master means it's a production release.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back to
>>>>>>>> Rajani's
>>>>>>>>>>>> point) everything is based on merges.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I am of the opinion that git flow provides a nice process. It
>>>>>>>> basically
>>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
>>>> releases
>>>>>>>>>>>> branches are branched off of that and merged into master and back
>>>> into
>>>>>>>>>>>> develop….etc
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Please read [1] it's a good read.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> And let's discuss,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -Sebastien
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> There is also the problem of cherry-picking.
>>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches for
>>>> each
>>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches. which
>>>> means
>>>>>>>>>>>> distinct commits for each branch and I don’t easily know which all
>>>>>>>> branches
>>>>>>>>>>>> my commit exists unless I do grep.
>>>>>>>>>>>>>> if we follow merging strategy properly, apart from the first
>>>> merge
>>>>>>>> of
>>>>>>>>>>>> the branch, everything else on top of it should be a painless
>>>> merge.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I think many of the bullet points are what we are currently
>>>> doing
>>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to stay
>>>> in
>>>>>>>> sync
>>>>>>>>>>>> with
>>>>>>>>>>>>>>> master, no back-merging). I also think that much of what we do
>>>> now
>>>>>>>> is
>>>>>>>>>>>> done
>>>>>>>>>>>>>>> the way it is simply because there *are* vast changes between
>>>>>>>> versions.
>>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the time.
>>>> If
>>>>>>>> its
>>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine, but some
>>>>>>>> quick
>>>>>>>>>>>> tests
>>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with having
>>>> single
>>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits where
>>>> each
>>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember
>>>> why we
>>>>>>>> went
>>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
>>>> somewhere, but
>>>>>>>>>>>> one of
>>>>>>>>>>>>>>> the nice things it provides is the ability for the release
>>>> manager
>>>>>>>> to
>>>>>>>>>>>>>>> control what changes are made during code freeze while giving
>>>>>>>> people a
>>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not always
>>>>>>>> followed).
>>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have their
>>>> own
>>>>>>>>>>>> repo and
>>>>>>>>>>>>>>> issue pull requests for bugfixes?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
>>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>>>>>>>>>>>> merge(merge -s
>>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
>>>> bring in
>>>>>>>> any
>>>>>>>>>>>>>>>> changes.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a major
>>>>>>>> rewrite, we
>>>>>>>>>>>>>>>> could stop merging to that branch and above and make the fix
>>>>>>>> manually.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a particular fix
>>>>>>>> for an
>>>>>>>>>>>> old
>>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does happen.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to branch x"
>>>> in
>>>>>>>> SVN
>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
>>>> branch(es).
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
>>>>>>>> has to
>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has changed?
>>>>>>>> Don't
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Stephen Turner
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
>>>> consider.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be error
>>>> prone
>>>>>>>> in
>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
>>>>>>>> related.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to see
>>>> if you
>>>>>>>>>>>>>>>> checked a
>>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In such a
>>>>>>>>>>>> situation,
>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
>>>>>>>> was no
>>>>>>>>>>>>>>>> longer
>>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to mark
>>>> it as
>>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure about
>>>> Git).
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the *forward
>>>>>>>> branches
>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
>>>>>>>> commit
>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>>>>>>>>>>>> contributor, I
>>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
>>>> cleanly
>>>>>>>>>>>> apply on
>>>>>>>>>>>>>>>>>>>> different branches.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
>>>>>>>> propose.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major release(ex:
>>>> 4.3.x,
>>>>>>>>>>>> 4.4.x,
>>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>>>>>>>> accordingly
>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>> the respective branches.
>>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
>>>>>>>> cherry-pick,
>>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
>>>> change or
>>>>>>>>>>>> fix and
>>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from release
>>>>>>>> branches
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
>>>>>>>>>>>> merged(either
>>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
>>>> trackable
>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>> git branch --contains
>>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal release
>>>>>>>> uptill
>>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time a
>>>> new
>>>>>>>> commit
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from master
>>>> to
>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
>>>> proactively
>>>>>>>>>>>> take
>>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to master on
>>>>>>>> code
>>>>>>>>>>>>>>>>>>>> complete through a merge.
>>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to release
>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor
>>>> release)
>>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author information
>>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>>>>>>>>>>>>>>>> <committer>
>>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
>>>>>>>> any bug
>>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
>>>> release(4.4)
>>>>>>>> only
>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release branch.
>>>>>>>> This
>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be using
>>>> jira
>>>>>>>> vote?)
>>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another branch
>>>>>>>>>>>>>>>> maintenance.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Ref:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> ~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>*™*
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> *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
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> 
>>>>>>> 
>>>>>>> *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.
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 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>*™*
>> 
> 
> 
> 
> -- 
> Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

Mike, Rajani,

Sebastien's point was that the current 4.4 is the closest we have to a
releasable branch. I don't mind enting on master but it will require
more fixing. In general all of this will require some RM work of all
committers. Please ammend my little proposal if you will.

On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
<Ra...@citrix.com> wrote:
> I agree with mike. I think we should start 4.5 from where master is now
> Also create a develop branch from master and continue future work for 4.6 there.
>
> I am not clear on how the release branches are going to be maintained.
> Are we saying we would create 4.5-RELEASE branch which is essentially same as our current -FORWARD branch and continue cherry-picking?
>
> I would prefer merges to cherry-picks.
> Also, I think we should allow committers to commit to the RELEASE branch after discussing about it on dev@ and have RM closely monitor them.
> Any commit intended for 4.5 RELEASE should be checked in after discussion in the 4.5 Release branch and then merged to develop branch.
>
>
> ~Rajani
>
>
>
> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <mi...@solidfire.com> wrote:
>
>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4 left off
>> and then merge features from develop into 4.5.
>>
>> Why don't we instead start 4.5 where master is now with the assumption that
>> since we are past Feature Freeze for 4.5 that master is stable enough?
>>
>>
>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <da...@gmail.com>
>> wrote:
>>
>>> so to start formulate a proposal:
>>>
>>> all work shall be done in a new branch (it is advisable to prefix your
>>> branches with your id)
>>> when working, features will be cherry-picked/merged into the release
>>> branch they are for and next into master.
>>> hotfixes will be done in <branchname>-hotfixes
>>>
>>> as transition we will
>>>
>>> rename 'master' to 'develop'
>>> branch a new 'master' from '4.4'
>>> branch '4.5' from the new 'master'
>>> merge any features from the new 'develop' to '4.5' and 'master'
>>>
>>>
>>>
>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <ru...@gmail.com>
>>> wrote:
>>>>
>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <ru...@gmail.com>
>>> wrote:
>>>>
>>>>>
>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com>
>>> wrote:
>>>>>
>>>>>> Let me ask the question, why have master be develop and a release
>>> branch be
>>>>>> "master"? If we are going to follow gitflow, why not just stick with
>>> the
>>>>>> norm? If master is the development branch, it might not be stable. I
>>> think
>>>>>> the goal here is that we have an obvious stable branch. Anyone could
>>> come
>>>>>> check out master and have the latest useable.
>>>>>
>>>>> I am in favor of following the norm, so ideally master should be our
>>> stable branch (agreed).
>>>>>
>>>>> The issue is with the transition.
>>>>>
>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally
>>> we could start a stable branch of this tag and build up bug fix releases
>>> all the way to 4.5 from there.
>>>>>
>>>>> But all features for 4.5 are already in master.
>>>>>
>>>>> So if we create a 'develop' branch of master and stabilize 'master'
>>> then develop is now started from a stable tag (4.4.0).
>>>>>
>>>>
>>>> *not* started from a stable tag, and merges will be tricky, no ?
>>>>
>>>>> So what's the best way to flip ? There is most likely some git magic
>>> that can we do.
>>>>>
>>>>>
>>>>> The new git workflow and the transition process need to be part of a
>>> proposal that we get consensus on.
>>>>>
>>>>> getting there :)
>>>>>
>>>>> -seb
>>>>>
>>>>>>
>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If you
>>>>>> completely squash history, you lose a tremendous amount of context,
>>> which I
>>>>>> use extensively to figure out why a bug is the way it is. Only knowing
>>> that
>>>>>> the branch was merged at a given point in time doesn't give any
>>> context.
>>>>>> Seeing the individual commit history of the branch helps to preserve
>>> the
>>>>>> rationale for why the code was written the way it was. In theory if
>>> every
>>>>>> change starts out as a branch (feature, hotfix, release), then why not
>>> just
>>>>>> merge the branch once it is in a good and acceptable state?
>>>>>>
>>>>>> I also agree with Mike that this will have to be a transition over
>>> time. It
>>>>>> will take some time to clean up master to the point where it can be
>>>>>> considered a solid stable branch. Possibly as part of the 4.5 release.
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <runseb@gmail.com
>>>>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Sebastien,
>>>>>>>>
>>>>>>>> It seems we can do what you are calling for is creating a branch
>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
>>> master,
>>>>>>>> 4.3. I would like to see people that want a feature or bug fix in a
>>>>>>>> branch make a fork of that branch and when that fork is working do a
>>>>>>>> cherry-pick. The -forward concept is now used for that but it is
>>>>>>>> broken because more then for one piece of work there are commits on
>>>>>>>> it. This caused me conflicts during the release. Especially painfull
>>>>>>>> as not all was intended to get into the release. We can create this
>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
>>> changes.
>>>>>>>
>>>>>>> Yes, that's what I am thinking about too, so +1
>>>>>>>
>>>>>>> Our master would become the -develop- in gitflow terms
>>>>>>> The release branch you mention would become the -master- in gitflow
>>> terms
>>>>>>>
>>>>>>> If we start now, indeed we can create 'release' from 4.4 release tag
>>>>>>> (voted and shipped).
>>>>>>>
>>>>>>> That means that to create 4.5 we will need to merge features back into
>>>>>>> 'release'. it might be messy because some of those features are
>>> already in
>>>>>>> our current master.
>>>>>>>
>>>>>>> But all of this will keep 'release' clean (we can keep track of bugs
>>> and
>>>>>>> features that are in it in CHANGES file etc..)
>>>>>>>
>>>>>>>
>>>>>>>> There is a question of control. Do we allow all committers to manage
>>>>>>>> the release? I am for that but can imagine not everybody is.
>>>>>>>>
>>>>>>>
>>>>>>> At first I would say that only the RM can commit to 'release'. As we
>>> get
>>>>>>> the CI in place  we could relax this and allow commits that pass the
>>> CI to
>>>>>>> get into 'release', but right now I would vote for a tighter control
>>> of
>>>>>>> 'release'.
>>>>>>>
>>>>>>>> rule number 1 will be: you are going to do something to the code, you
>>>>>>>> start by creating a branch.
>>>>>>>>
>>>>>>>> right?
>>>>>>>>
>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
>>> runseb@gmail.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hey everyone,
>>>>>>>>>>
>>>>>>>>>> I've been a developer for a handful of years and have had my share
>>> of
>>>>>>>>>> experience with different version control systems.  I've used (for
>>>>>>> better
>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>>>>>>>>>
>>>>>>>>>> Each of these solutions offers their own unique set of features,
>>>>>>> strengths
>>>>>>>>>> and weaknesses.  As there are so many systems that are good at
>>> specific
>>>>>>>>>> things, it seems best to use the features that the chosen system is
>>>>>>> best at.
>>>>>>>>>>
>>>>>>>>>> Git is great at branching, merging and using that structure to
>>>>>>> maintain and
>>>>>>>>>> control how changes get into the primary branches.  Git tools even
>>> make
>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
>>> branching
>>>>>>> and
>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to NOT
>>> make
>>>>>>> use
>>>>>>>>>> of these built-in capabilities.
>>>>>>>>>>
>>>>>>>>>> In addition to that, I know that the current method of change
>>>>>>> management is
>>>>>>>>>> incredibly frustrating to work with, and works directly against the
>>>>>>> way a
>>>>>>>>>> typical Git user would expect it to be structured.  I should NEVER
>>> have
>>>>>>>>>> problem compiling and running something on master.  I should not
>>> have
>>>>>>>>>> problems building anything on a release branch.  A feature/bugfix
>>>>>>> branch is
>>>>>>>>>> where things can be, and often are, broken or unstable.  There have
>>>>>>> been
>>>>>>>>>> many times working in Cloudstack where I've had to search for a
>>> stable
>>>>>>>>>> revision on master, and that's just plain wrong.
>>>>>>>>>>
>>>>>>>>>> I do realize that having this many developers working on so many
>>>>>>> features
>>>>>>>>>> and bugfixes will result in a large number of branches.  I don't
>>>>>>> believe
>>>>>>>>>> this is a good argument against using a branching method, though -
>>> I
>>>>>>>>>> believe that the current system is even more confusing and
>>> difficult
>>>>>>> to use.
>>>>>>>>>>
>>>>>>>>>> I could pontificate on change management quite a bit more, but my
>>>>>>> opinion
>>>>>>>>>> in summary would basically be:  use Git the way it was meant to be
>>>>>>> used,
>>>>>>>>>> and things will be better.  Just my two cents.
>>>>>>>>>>
>>>>>>>>>> Sam
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sam, I think we are in agreement (at least with folks who responded
>>> to
>>>>>>> this thread).
>>>>>>>>> Or maybe I am not reading your mail right and you don't agree with
>>> Leo ?
>>>>>>>>>
>>>>>>>>> My own take and reason for calling for a change we are currently
>>> doing
>>>>>>> things is mostly due to the way we release.
>>>>>>>>>
>>>>>>>>> I would like to see a stable master (and I think we are in agreement
>>>>>>> with that).
>>>>>>>>> That means that development should not happen on master and that
>>> every
>>>>>>> commit that lands on master should be shippable.
>>>>>>>>>
>>>>>>>>> I personally have no issues with cherry-picking. So I would be fine
>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
>>>>>>>>> The end result is that the next commit on master would still mean
>>>>>>> master is shippable/releasable.
>>>>>>>>>
>>>>>>>>> If we agree with this basic concept. The question becomes how do we
>>> get
>>>>>>> there, considering that master is now full of dev work and potential
>>> bug.
>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and previous
>>>>>>> release branches.
>>>>>>>>>
>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our way
>>> back,
>>>>>>> merging the new features that are already in master into the new
>>> master
>>>>>>> (based on 4.4).
>>>>>>>>> This could be quite complicated but we need to do it (or something
>>> like
>>>>>>> it).
>>>>>>>>>
>>>>>>>>> To move forward, we should make a proposal to the list and call for
>>> a
>>>>>>> vote.
>>>>>>>>>
>>>>>>>>> Any takers to start a wiki page proposing a new git process and how
>>> we
>>>>>>> could move to it (transition path) ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Sebastien
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>>>>>>> LSimons@schubergphilis.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey folks,
>>>>>>>>>>>
>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and implement
>>> this?
>>>>>>>>>>>
>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
>>>>>>> committer so
>>>>>>>>>>> its not that practical for me to volunteer!
>>>>>>>>>>>
>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
>>>>>>>>>>>
>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>>>>>>>>>
>>>>>>>>>>> which might be easier to read.
>>>>>>>>>>>
>>>>>>>>>>> Similarly, the git-flow scripts that help out with implementing
>>> this
>>>>>>> stuff
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/nvie/gitflow
>>>>>>>>>>>
>>>>>>>>>>> they also describe the relationship between gitflow and dealing
>>> with
>>>>>>>>>>> multiple remotes
>>>>>>>>>>>
>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>>>>>>>>>>>
>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in support
>>> for
>>>>>>>>>>> git-flow
>>>>>>>>>>>
>>>>>>>>>>> http://www.sourcetreeapp.com/
>>>>>>>>>>>
>>>>>>>>>>> Because cloudstack currently is full of rebasing and squashing and
>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
>>> visualization
>>>>>>> tool
>>>>>>>>>>> (like this or gitk or ...) right now, but it would be *great* to
>>> have
>>>>>>> going
>>>>>>>>>>> forward.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> cheers,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Leo
>>>>>>>>>>>
>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <runseb@gmail.com
>>>>
>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I would like to re-start this discussion.
>>>>>>>>>>>>
>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>>>>>>>>>
>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>>
>>>>>>>>>>>> Thinking about our release procedure, we clearly need more tests
>>> and
>>>>>>> a
>>>>>>>>>>> CI. However it looks like this is going to take some time.
>>>>>>>>>>>>
>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
>>> agreeing
>>>>>>> to
>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just need to
>>>>>>> agree on
>>>>>>>>>>> the git workflow.
>>>>>>>>>>>>
>>>>>>>>>>>> Right now Master is really a development branch, we should make
>>> it a
>>>>>>>>>>> stable branch for production with very few commits.
>>>>>>>>>>>> This does not mean that we would release less, in contrary this
>>> would
>>>>>>>>>>> ensure that a commit to master means it's a production release.
>>>>>>>>>>>>
>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back to
>>>>>>> Rajani's
>>>>>>>>>>> point) everything is based on merges.
>>>>>>>>>>>>
>>>>>>>>>>>> I am of the opinion that git flow provides a nice process. It
>>>>>>> basically
>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
>>> releases
>>>>>>>>>>> branches are branched off of that and merged into master and back
>>> into
>>>>>>>>>>> develop….etc
>>>>>>>>>>>>
>>>>>>>>>>>> Please read [1] it's a good read.
>>>>>>>>>>>>
>>>>>>>>>>>> And let's discuss,
>>>>>>>>>>>>
>>>>>>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>>
>>>>>>>>>>>> -Sebastien
>>>>>>>>>>>>
>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> There is also the problem of cherry-picking.
>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches for
>>> each
>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches. which
>>> means
>>>>>>>>>>> distinct commits for each branch and I don’t easily know which all
>>>>>>> branches
>>>>>>>>>>> my commit exists unless I do grep.
>>>>>>>>>>>>> if we follow merging strategy properly, apart from the first
>>> merge
>>>>>>> of
>>>>>>>>>>> the branch, everything else on top of it should be a painless
>>> merge.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think many of the bullet points are what we are currently
>>> doing
>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to stay
>>> in
>>>>>>> sync
>>>>>>>>>>> with
>>>>>>>>>>>>>> master, no back-merging). I also think that much of what we do
>>> now
>>>>>>> is
>>>>>>>>>>> done
>>>>>>>>>>>>>> the way it is simply because there *are* vast changes between
>>>>>>> versions.
>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the time.
>>> If
>>>>>>> its
>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine, but some
>>>>>>> quick
>>>>>>>>>>> tests
>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with having
>>> single
>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits where
>>> each
>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember
>>> why we
>>>>>>> went
>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
>>> somewhere, but
>>>>>>>>>>> one of
>>>>>>>>>>>>>> the nice things it provides is the ability for the release
>>> manager
>>>>>>> to
>>>>>>>>>>>>>> control what changes are made during code freeze while giving
>>>>>>> people a
>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not always
>>>>>>> followed).
>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have their
>>> own
>>>>>>>>>>> repo and
>>>>>>>>>>>>>> issue pull requests for bugfixes?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>>>>>>>>>>> merge(merge -s
>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
>>> bring in
>>>>>>> any
>>>>>>>>>>>>>>> changes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a major
>>>>>>> rewrite, we
>>>>>>>>>>>>>>> could stop merging to that branch and above and make the fix
>>>>>>> manually.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a particular fix
>>>>>>> for an
>>>>>>>>>>> old
>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does happen.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to branch x"
>>> in
>>>>>>> SVN
>>>>>>>>>>> and
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
>>> branch(es).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
>>>>>>> has to
>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has changed?
>>>>>>> Don't
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Stephen Turner
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
>>> consider.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be error
>>> prone
>>>>>>> in
>>>>>>>>>>> that
>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
>>>>>>>>>>> branches
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
>>>>>>> related.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to see
>>> if you
>>>>>>>>>>>>>>> checked a
>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In such a
>>>>>>>>>>> situation,
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
>>>>>>> was no
>>>>>>>>>>>>>>> longer
>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to mark
>>> it as
>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure about
>>> Git).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the *forward
>>>>>>> branches
>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
>>>>>>> commit
>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>>>>>>>>>>> contributor, I
>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
>>> cleanly
>>>>>>>>>>> apply on
>>>>>>>>>>>>>>>>>>> different branches.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
>>>>>>> propose.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major release(ex:
>>> 4.3.x,
>>>>>>>>>>> 4.4.x,
>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>>>>>>> accordingly
>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> the respective branches.
>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
>>>>>>> branches
>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
>>>>>>> cherry-pick,
>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
>>> change or
>>>>>>>>>>> fix and
>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from release
>>>>>>> branches
>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
>>>>>>>>>>> merged(either
>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
>>> trackable
>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>> git branch --contains
>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal release
>>>>>>> uptill
>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time a
>>> new
>>>>>>> commit
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from master
>>> to
>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
>>> proactively
>>>>>>>>>>> take
>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to master on
>>>>>>> code
>>>>>>>>>>>>>>>>>>> complete through a merge.
>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to release
>>>>>>> branches
>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor
>>> release)
>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author information
>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>>>>>>>>>>>>>>> <committer>
>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
>>>>>>> any bug
>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
>>> release(4.4)
>>>>>>> only
>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release branch.
>>>>>>> This
>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be using
>>> jira
>>>>>>> vote?)
>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another branch
>>>>>>>>>>>>>>> maintenance.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ref:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ~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>*™*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> *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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> *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.
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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>*™*
>



-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

I agree with mike. I think we should start 4.5 from where master is now 
Also create a develop branch from master and continue future work for 4.6 there.

I am not clear on how the release branches are going to be maintained.
Are we saying we would create 4.5-RELEASE branch which is essentially same as our current -FORWARD branch and continue cherry-picking?

I would prefer merges to cherry-picks. 
Also, I think we should allow committers to commit to the RELEASE branch after discussing about it on dev@ and have RM closely monitor them.
Any commit intended for 4.5 RELEASE should be checked in after discussion in the 4.5 Release branch and then merged to develop branch.


~Rajani



On 24-Jul-2014, at 1:14 am, Mike Tutkowski <mi...@solidfire.com> wrote:

> Per earlier e-mails, I don't think we want to start 4.5 where 4.4 left off
> and then merge features from develop into 4.5.
> 
> Why don't we instead start 4.5 where master is now with the assumption that
> since we are past Feature Freeze for 4.5 that master is stable enough?
> 
> 
> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <da...@gmail.com>
> wrote:
> 
>> so to start formulate a proposal:
>> 
>> all work shall be done in a new branch (it is advisable to prefix your
>> branches with your id)
>> when working, features will be cherry-picked/merged into the release
>> branch they are for and next into master.
>> hotfixes will be done in <branchname>-hotfixes
>> 
>> as transition we will
>> 
>> rename 'master' to 'develop'
>> branch a new 'master' from '4.4'
>> branch '4.5' from the new 'master'
>> merge any features from the new 'develop' to '4.5' and 'master'
>> 
>> 
>> 
>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>>> 
>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>>> 
>>>> 
>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com>
>> wrote:
>>>> 
>>>>> Let me ask the question, why have master be develop and a release
>> branch be
>>>>> "master"? If we are going to follow gitflow, why not just stick with
>> the
>>>>> norm? If master is the development branch, it might not be stable. I
>> think
>>>>> the goal here is that we have an obvious stable branch. Anyone could
>> come
>>>>> check out master and have the latest useable.
>>>> 
>>>> I am in favor of following the norm, so ideally master should be our
>> stable branch (agreed).
>>>> 
>>>> The issue is with the transition.
>>>> 
>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally
>> we could start a stable branch of this tag and build up bug fix releases
>> all the way to 4.5 from there.
>>>> 
>>>> But all features for 4.5 are already in master.
>>>> 
>>>> So if we create a 'develop' branch of master and stabilize 'master'
>> then develop is now started from a stable tag (4.4.0).
>>>> 
>>> 
>>> *not* started from a stable tag, and merges will be tricky, no ?
>>> 
>>>> So what's the best way to flip ? There is most likely some git magic
>> that can we do.
>>>> 
>>>> 
>>>> The new git workflow and the transition process need to be part of a
>> proposal that we get consensus on.
>>>> 
>>>> getting there :)
>>>> 
>>>> -seb
>>>> 
>>>>> 
>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If you
>>>>> completely squash history, you lose a tremendous amount of context,
>> which I
>>>>> use extensively to figure out why a bug is the way it is. Only knowing
>> that
>>>>> the branch was merged at a given point in time doesn't give any
>> context.
>>>>> Seeing the individual commit history of the branch helps to preserve
>> the
>>>>> rationale for why the code was written the way it was. In theory if
>> every
>>>>> change starts out as a branch (feature, hotfix, release), then why not
>> just
>>>>> merge the branch once it is in a good and acceptable state?
>>>>> 
>>>>> I also agree with Mike that this will have to be a transition over
>> time. It
>>>>> will take some time to clean up master to the point where it can be
>>>>> considered a solid stable branch. Possibly as part of the 4.5 release.
>>>>> 
>>>>> 
>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <runseb@gmail.com
>>> 
>>>>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Sebastien,
>>>>>>> 
>>>>>>> It seems we can do what you are calling for is creating a branch
>>>>>>> called 'release'. We can merge back into that branch from 4.4,
>> master,
>>>>>>> 4.3. I would like to see people that want a feature or bug fix in a
>>>>>>> branch make a fork of that branch and when that fork is working do a
>>>>>>> cherry-pick. The -forward concept is now used for that but it is
>>>>>>> broken because more then for one piece of work there are commits on
>>>>>>> it. This caused me conflicts during the release. Especially painfull
>>>>>>> as not all was intended to get into the release. We can create this
>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
>> changes.
>>>>>> 
>>>>>> Yes, that's what I am thinking about too, so +1
>>>>>> 
>>>>>> Our master would become the -develop- in gitflow terms
>>>>>> The release branch you mention would become the -master- in gitflow
>> terms
>>>>>> 
>>>>>> If we start now, indeed we can create 'release' from 4.4 release tag
>>>>>> (voted and shipped).
>>>>>> 
>>>>>> That means that to create 4.5 we will need to merge features back into
>>>>>> 'release'. it might be messy because some of those features are
>> already in
>>>>>> our current master.
>>>>>> 
>>>>>> But all of this will keep 'release' clean (we can keep track of bugs
>> and
>>>>>> features that are in it in CHANGES file etc..)
>>>>>> 
>>>>>> 
>>>>>>> There is a question of control. Do we allow all committers to manage
>>>>>>> the release? I am for that but can imagine not everybody is.
>>>>>>> 
>>>>>> 
>>>>>> At first I would say that only the RM can commit to 'release'. As we
>> get
>>>>>> the CI in place  we could relax this and allow commits that pass the
>> CI to
>>>>>> get into 'release', but right now I would vote for a tighter control
>> of
>>>>>> 'release'.
>>>>>> 
>>>>>>> rule number 1 will be: you are going to do something to the code, you
>>>>>>> start by creating a branch.
>>>>>>> 
>>>>>>> right?
>>>>>>> 
>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
>> runseb@gmail.com>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hey everyone,
>>>>>>>>> 
>>>>>>>>> I've been a developer for a handful of years and have had my share
>> of
>>>>>>>>> experience with different version control systems.  I've used (for
>>>>>> better
>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>>>>>>>> 
>>>>>>>>> Each of these solutions offers their own unique set of features,
>>>>>> strengths
>>>>>>>>> and weaknesses.  As there are so many systems that are good at
>> specific
>>>>>>>>> things, it seems best to use the features that the chosen system is
>>>>>> best at.
>>>>>>>>> 
>>>>>>>>> Git is great at branching, merging and using that structure to
>>>>>> maintain and
>>>>>>>>> control how changes get into the primary branches.  Git tools even
>> make
>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
>> branching
>>>>>> and
>>>>>>>>> merging that much easier.  It would seem counter-intuitive to NOT
>> make
>>>>>> use
>>>>>>>>> of these built-in capabilities.
>>>>>>>>> 
>>>>>>>>> In addition to that, I know that the current method of change
>>>>>> management is
>>>>>>>>> incredibly frustrating to work with, and works directly against the
>>>>>> way a
>>>>>>>>> typical Git user would expect it to be structured.  I should NEVER
>> have
>>>>>>>>> problem compiling and running something on master.  I should not
>> have
>>>>>>>>> problems building anything on a release branch.  A feature/bugfix
>>>>>> branch is
>>>>>>>>> where things can be, and often are, broken or unstable.  There have
>>>>>> been
>>>>>>>>> many times working in Cloudstack where I've had to search for a
>> stable
>>>>>>>>> revision on master, and that's just plain wrong.
>>>>>>>>> 
>>>>>>>>> I do realize that having this many developers working on so many
>>>>>> features
>>>>>>>>> and bugfixes will result in a large number of branches.  I don't
>>>>>> believe
>>>>>>>>> this is a good argument against using a branching method, though -
>> I
>>>>>>>>> believe that the current system is even more confusing and
>> difficult
>>>>>> to use.
>>>>>>>>> 
>>>>>>>>> I could pontificate on change management quite a bit more, but my
>>>>>> opinion
>>>>>>>>> in summary would basically be:  use Git the way it was meant to be
>>>>>> used,
>>>>>>>>> and things will be better.  Just my two cents.
>>>>>>>>> 
>>>>>>>>> Sam
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Sam, I think we are in agreement (at least with folks who responded
>> to
>>>>>> this thread).
>>>>>>>> Or maybe I am not reading your mail right and you don't agree with
>> Leo ?
>>>>>>>> 
>>>>>>>> My own take and reason for calling for a change we are currently
>> doing
>>>>>> things is mostly due to the way we release.
>>>>>>>> 
>>>>>>>> I would like to see a stable master (and I think we are in agreement
>>>>>> with that).
>>>>>>>> That means that development should not happen on master and that
>> every
>>>>>> commit that lands on master should be shippable.
>>>>>>>> 
>>>>>>>> I personally have no issues with cherry-picking. So I would be fine
>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
>>>>>>>> The end result is that the next commit on master would still mean
>>>>>> master is shippable/releasable.
>>>>>>>> 
>>>>>>>> If we agree with this basic concept. The question becomes how do we
>> get
>>>>>> there, considering that master is now full of dev work and potential
>> bug.
>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and previous
>>>>>> release branches.
>>>>>>>> 
>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our way
>> back,
>>>>>> merging the new features that are already in master into the new
>> master
>>>>>> (based on 4.4).
>>>>>>>> This could be quite complicated but we need to do it (or something
>> like
>>>>>> it).
>>>>>>>> 
>>>>>>>> To move forward, we should make a proposal to the list and call for
>> a
>>>>>> vote.
>>>>>>>> 
>>>>>>>> Any takers to start a wiki page proposing a new git process and how
>> we
>>>>>> could move to it (transition path) ?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -Sebastien
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>>>>>> LSimons@schubergphilis.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Hey folks,
>>>>>>>>>> 
>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and implement
>> this?
>>>>>>>>>> 
>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
>>>>>> committer so
>>>>>>>>>> its not that practical for me to volunteer!
>>>>>>>>>> 
>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
>>>>>>>>>> 
>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>>>>>>>> 
>>>>>>>>>> which might be easier to read.
>>>>>>>>>> 
>>>>>>>>>> Similarly, the git-flow scripts that help out with implementing
>> this
>>>>>> stuff
>>>>>>>>>> 
>>>>>>>>>> https://github.com/nvie/gitflow
>>>>>>>>>> 
>>>>>>>>>> they also describe the relationship between gitflow and dealing
>> with
>>>>>>>>>> multiple remotes
>>>>>>>>>> 
>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>>>>>>>>>> 
>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in support
>> for
>>>>>>>>>> git-flow
>>>>>>>>>> 
>>>>>>>>>> http://www.sourcetreeapp.com/
>>>>>>>>>> 
>>>>>>>>>> Because cloudstack currently is full of rebasing and squashing and
>>>>>>>>>> cherry-picking, you get very little benefit from a tree
>> visualization
>>>>>> tool
>>>>>>>>>> (like this or gitk or ...) right now, but it would be *great* to
>> have
>>>>>> going
>>>>>>>>>> forward.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> cheers,
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Leo
>>>>>>>>>> 
>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <runseb@gmail.com
>>> 
>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> I would like to re-start this discussion.
>>>>>>>>>>> 
>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>>>>>>>> 
>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>> 
>>>>>>>>>>> Thinking about our release procedure, we clearly need more tests
>> and
>>>>>> a
>>>>>>>>>> CI. However it looks like this is going to take some time.
>>>>>>>>>>> 
>>>>>>>>>>> In the meantime I think there is nothing preventing us from
>> agreeing
>>>>>> to
>>>>>>>>>> 'git practices', we don't need tests or new infra, we just need to
>>>>>> agree on
>>>>>>>>>> the git workflow.
>>>>>>>>>>> 
>>>>>>>>>>> Right now Master is really a development branch, we should make
>> it a
>>>>>>>>>> stable branch for production with very few commits.
>>>>>>>>>>> This does not mean that we would release less, in contrary this
>> would
>>>>>>>>>> ensure that a commit to master means it's a production release.
>>>>>>>>>>> 
>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back to
>>>>>> Rajani's
>>>>>>>>>> point) everything is based on merges.
>>>>>>>>>>> 
>>>>>>>>>>> I am of the opinion that git flow provides a nice process. It
>>>>>> basically
>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
>> releases
>>>>>>>>>> branches are branched off of that and merged into master and back
>> into
>>>>>>>>>> develop….etc
>>>>>>>>>>> 
>>>>>>>>>>> Please read [1] it's a good read.
>>>>>>>>>>> 
>>>>>>>>>>> And let's discuss,
>>>>>>>>>>> 
>>>>>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>> 
>>>>>>>>>>> -Sebastien
>>>>>>>>>>> 
>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> There is also the problem of cherry-picking.
>>>>>>>>>>>> As a contributor, I always endup creating multiple patches for
>> each
>>>>>>>>>> branch as they don’t cleanly apply on the upward branches. which
>> means
>>>>>>>>>> distinct commits for each branch and I don’t easily know which all
>>>>>> branches
>>>>>>>>>> my commit exists unless I do grep.
>>>>>>>>>>>> if we follow merging strategy properly, apart from the first
>> merge
>>>>>> of
>>>>>>>>>> the branch, everything else on top of it should be a painless
>> merge.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I think many of the bullet points are what we are currently
>> doing
>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to stay
>> in
>>>>>> sync
>>>>>>>>>> with
>>>>>>>>>>>>> master, no back-merging). I also think that much of what we do
>> now
>>>>>> is
>>>>>>>>>> done
>>>>>>>>>>>>> the way it is simply because there *are* vast changes between
>>>>>> versions.
>>>>>>>>>>>>> Classes are getting shuffled around and changed all the time.
>> If
>>>>>> its
>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine, but some
>>>>>> quick
>>>>>>>>>> tests
>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with having
>> single
>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits where
>> each
>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember
>> why we
>>>>>> went
>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
>> somewhere, but
>>>>>>>>>> one of
>>>>>>>>>>>>> the nice things it provides is the ability for the release
>> manager
>>>>>> to
>>>>>>>>>>>>> control what changes are made during code freeze while giving
>>>>>> people a
>>>>>>>>>>>>> place to stage fixes (though admittedly this is not always
>>>>>> followed).
>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have their
>> own
>>>>>>>>>> repo and
>>>>>>>>>>>>> issue pull requests for bugfixes?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Any other suggestions/objections/comments??
>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>>>>>>>>>> merge(merge -s
>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
>> bring in
>>>>>> any
>>>>>>>>>>>>>> changes.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a major
>>>>>> rewrite, we
>>>>>>>>>>>>>> could stop merging to that branch and above and make the fix
>>>>>> manually.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a particular fix
>>>>>> for an
>>>>>>>>>> old
>>>>>>>>>>>>>>>> release may not apply to newer versions. That does happen.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to branch x"
>> in
>>>>>> SVN
>>>>>>>>>> and
>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
>> branch(es).
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
>>>>>> has to
>>>>>>>>>> be
>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has changed?
>>>>>> Don't
>>>>>>>>>> the
>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Stephen Turner
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
>> consider.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be error
>> prone
>>>>>> in
>>>>>>>>>> that
>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
>>>>>>>>>> branches
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
>>>>>> related.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to see
>> if you
>>>>>>>>>>>>>> checked a
>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In such a
>>>>>>>>>> situation,
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
>>>>>> was no
>>>>>>>>>>>>>> longer
>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to mark
>> it as
>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure about
>> Git).
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the *forward
>>>>>> branches
>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
>>>>>> commit
>>>>>>>>>> has
>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>>>>>>>>>> contributor, I
>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
>> cleanly
>>>>>>>>>> apply on
>>>>>>>>>>>>>>>>>> different branches.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
>>>>>> propose.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major release(ex:
>> 4.3.x,
>>>>>>>>>> 4.4.x,
>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>>>>>> accordingly
>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> the respective branches.
>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
>>>>>> branches
>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
>>>>>> cherry-pick,
>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
>> change or
>>>>>>>>>> fix and
>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from release
>>>>>> branches
>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
>>>>>>>>>> merged(either
>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
>> trackable
>>>>>>>>>> with
>>>>>>>>>>>>>>>>>> git branch --contains
>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal release
>>>>>> uptill
>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time a
>> new
>>>>>> commit
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from master
>> to
>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
>> proactively
>>>>>>>>>> take
>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to master on
>>>>>> code
>>>>>>>>>>>>>>>>>> complete through a merge.
>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to release
>>>>>> branches
>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor
>> release)
>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author information
>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>>>>>>>>>>>>>> <committer>
>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
>>>>>> any bug
>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
>> release(4.4)
>>>>>> only
>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release branch.
>>>>>> This
>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be using
>> jira
>>>>>> vote?)
>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another branch
>>>>>>>>>>>>>> maintenance.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Ref:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>> 
>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> ~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>*™*
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> *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
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> 
>>>>> *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.
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> 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: [DISCUSS][PROPOSAL] git workflow

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

Per earlier e-mails, I don't think we want to start 4.5 where 4.4 left off
and then merge features from develop into 4.5.

Why don't we instead start 4.5 where master is now with the assumption that
since we are past Feature Freeze for 4.5 that master is stable enough?


On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <da...@gmail.com>
wrote:

> so to start formulate a proposal:
>
> all work shall be done in a new branch (it is advisable to prefix your
> branches with your id)
> when working, features will be cherry-picked/merged into the release
> branch they are for and next into master.
> hotfixes will be done in <branchname>-hotfixes
>
> as transition we will
>
> rename 'master' to 'develop'
> branch a new 'master' from '4.4'
> branch '4.5' from the new 'master'
> merge any features from the new 'develop' to '4.5' and 'master'
>
>
>
> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> >
> > On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> >
> >>
> >> On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com>
> wrote:
> >>
> >>> Let me ask the question, why have master be develop and a release
> branch be
> >>> "master"? If we are going to follow gitflow, why not just stick with
> the
> >>> norm? If master is the development branch, it might not be stable. I
> think
> >>> the goal here is that we have an obvious stable branch. Anyone could
> come
> >>> check out master and have the latest useable.
> >>
> >> I am in favor of following the norm, so ideally master should be our
> stable branch (agreed).
> >>
> >> The issue is with the transition.
> >>
> >> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally
> we could start a stable branch of this tag and build up bug fix releases
> all the way to 4.5 from there.
> >>
> >> But all features for 4.5 are already in master.
> >>
> >> So if we create a 'develop' branch of master and stabilize 'master'
> then develop is now started from a stable tag (4.4.0).
> >>
> >
> > *not* started from a stable tag, and merges will be tricky, no ?
> >
> >> So what's the best way to flip ? There is most likely some git magic
> that can we do.
> >>
> >>
> >> The new git workflow and the transition process need to be part of a
> proposal that we get consensus on.
> >>
> >> getting there :)
> >>
> >> -seb
> >>
> >>>
> >>> Also, I'm struggling to understand the benefit of cherry-pick. If you
> >>> completely squash history, you lose a tremendous amount of context,
> which I
> >>> use extensively to figure out why a bug is the way it is. Only knowing
> that
> >>> the branch was merged at a given point in time doesn't give any
> context.
> >>> Seeing the individual commit history of the branch helps to preserve
> the
> >>> rationale for why the code was written the way it was. In theory if
> every
> >>> change starts out as a branch (feature, hotfix, release), then why not
> just
> >>> merge the branch once it is in a good and acceptable state?
> >>>
> >>> I also agree with Mike that this will have to be a transition over
> time. It
> >>> will take some time to clean up master to the point where it can be
> >>> considered a solid stable branch. Possibly as part of the 4.5 release.
> >>>
> >>>
> >>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <runseb@gmail.com
> >
> >>> wrote:
> >>>
> >>>>
> >>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Sebastien,
> >>>>>
> >>>>> It seems we can do what you are calling for is creating a branch
> >>>>> called 'release'. We can merge back into that branch from 4.4,
> master,
> >>>>> 4.3. I would like to see people that want a feature or bug fix in a
> >>>>> branch make a fork of that branch and when that fork is working do a
> >>>>> cherry-pick. The -forward concept is now used for that but it is
> >>>>> broken because more then for one piece of work there are commits on
> >>>>> it. This caused me conflicts during the release. Especially painfull
> >>>>> as not all was intended to get into the release. We can create this
> >>>>> 'release' branch now on the basis of 4.4 and start pulling in
> changes.
> >>>>
> >>>> Yes, that's what I am thinking about too, so +1
> >>>>
> >>>> Our master would become the -develop- in gitflow terms
> >>>> The release branch you mention would become the -master- in gitflow
> terms
> >>>>
> >>>> If we start now, indeed we can create 'release' from 4.4 release tag
> >>>> (voted and shipped).
> >>>>
> >>>> That means that to create 4.5 we will need to merge features back into
> >>>> 'release'. it might be messy because some of those features are
> already in
> >>>> our current master.
> >>>>
> >>>> But all of this will keep 'release' clean (we can keep track of bugs
> and
> >>>> features that are in it in CHANGES file etc..)
> >>>>
> >>>>
> >>>>> There is a question of control. Do we allow all committers to manage
> >>>>> the release? I am for that but can imagine not everybody is.
> >>>>>
> >>>>
> >>>> At first I would say that only the RM can commit to 'release'. As we
> get
> >>>> the CI in place  we could relax this and allow commits that pass the
> CI to
> >>>> get into 'release', but right now I would vote for a tighter control
> of
> >>>> 'release'.
> >>>>
> >>>>> rule number 1 will be: you are going to do something to the code, you
> >>>>> start by creating a branch.
> >>>>>
> >>>>> right?
> >>>>>
> >>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
> runseb@gmail.com>
> >>>> wrote:
> >>>>>>
> >>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> Hey everyone,
> >>>>>>>
> >>>>>>> I've been a developer for a handful of years and have had my share
> of
> >>>>>>> experience with different version control systems.  I've used (for
> >>>> better
> >>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>>>>>
> >>>>>>> Each of these solutions offers their own unique set of features,
> >>>> strengths
> >>>>>>> and weaknesses.  As there are so many systems that are good at
> specific
> >>>>>>> things, it seems best to use the features that the chosen system is
> >>>> best at.
> >>>>>>>
> >>>>>>> Git is great at branching, merging and using that structure to
> >>>> maintain and
> >>>>>>> control how changes get into the primary branches.  Git tools even
> make
> >>>>>>> this easy by integrating directly into the "Gitflow" to make
> branching
> >>>> and
> >>>>>>> merging that much easier.  It would seem counter-intuitive to NOT
> make
> >>>> use
> >>>>>>> of these built-in capabilities.
> >>>>>>>
> >>>>>>> In addition to that, I know that the current method of change
> >>>> management is
> >>>>>>> incredibly frustrating to work with, and works directly against the
> >>>> way a
> >>>>>>> typical Git user would expect it to be structured.  I should NEVER
> have
> >>>>>>> problem compiling and running something on master.  I should not
> have
> >>>>>>> problems building anything on a release branch.  A feature/bugfix
> >>>> branch is
> >>>>>>> where things can be, and often are, broken or unstable.  There have
> >>>> been
> >>>>>>> many times working in Cloudstack where I've had to search for a
> stable
> >>>>>>> revision on master, and that's just plain wrong.
> >>>>>>>
> >>>>>>> I do realize that having this many developers working on so many
> >>>> features
> >>>>>>> and bugfixes will result in a large number of branches.  I don't
> >>>> believe
> >>>>>>> this is a good argument against using a branching method, though -
> I
> >>>>>>> believe that the current system is even more confusing and
> difficult
> >>>> to use.
> >>>>>>>
> >>>>>>> I could pontificate on change management quite a bit more, but my
> >>>> opinion
> >>>>>>> in summary would basically be:  use Git the way it was meant to be
> >>>> used,
> >>>>>>> and things will be better.  Just my two cents.
> >>>>>>>
> >>>>>>> Sam
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> Sam, I think we are in agreement (at least with folks who responded
> to
> >>>> this thread).
> >>>>>> Or maybe I am not reading your mail right and you don't agree with
> Leo ?
> >>>>>>
> >>>>>> My own take and reason for calling for a change we are currently
> doing
> >>>> things is mostly due to the way we release.
> >>>>>>
> >>>>>> I would like to see a stable master (and I think we are in agreement
> >>>> with that).
> >>>>>> That means that development should not happen on master and that
> every
> >>>> commit that lands on master should be shippable.
> >>>>>>
> >>>>>> I personally have no issues with cherry-picking. So I would be fine
> >>>> cherry picking from a hot-fix branch into master, to fix a bug.
> >>>>>> The end result is that the next commit on master would still mean
> >>>> master is shippable/releasable.
> >>>>>>
> >>>>>> If we agree with this basic concept. The question becomes how do we
> get
> >>>> there, considering that master is now full of dev work and potential
> bug.
> >>>>>> The only releasable product we have are on the 4.3, 4.4 and previous
> >>>> release branches.
> >>>>>>
> >>>>>> Ideally, I would like to see master becomes 4.4. And work our way
> back,
> >>>> merging the new features that are already in master into the new
> master
> >>>> (based on 4.4).
> >>>>>> This could be quite complicated but we need to do it (or something
> like
> >>>> it).
> >>>>>>
> >>>>>> To move forward, we should make a proposal to the list and call for
> a
> >>>> vote.
> >>>>>>
> >>>>>> Any takers to start a wiki page proposing a new git process and how
> we
> >>>> could move to it (transition path) ?
> >>>>>>
> >>>>>>
> >>>>>> -Sebastien
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
> >>>> LSimons@schubergphilis.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hey folks,
> >>>>>>>>
> >>>>>>>> With 4.4.0 tagged, is now an opportune time to go and implement
> this?
> >>>>>>>>
> >>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
> >>>> committer so
> >>>>>>>> its not that practical for me to volunteer!
> >>>>>>>>
> >>>>>>>> I wanted to point out atlassian’s description of gitflow
> >>>>>>>>
> >>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
> >>>>>>>>
> >>>>>>>> which might be easier to read.
> >>>>>>>>
> >>>>>>>> Similarly, the git-flow scripts that help out with implementing
> this
> >>>> stuff
> >>>>>>>>
> >>>>>>>> https://github.com/nvie/gitflow
> >>>>>>>>
> >>>>>>>> they also describe the relationship between gitflow and dealing
> with
> >>>>>>>> multiple remotes
> >>>>>>>>
> >>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
> >>>>>>>>
> >>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in support
> for
> >>>>>>>> git-flow
> >>>>>>>>
> >>>>>>>> http://www.sourcetreeapp.com/
> >>>>>>>>
> >>>>>>>> Because cloudstack currently is full of rebasing and squashing and
> >>>>>>>> cherry-picking, you get very little benefit from a tree
> visualization
> >>>> tool
> >>>>>>>> (like this or gitk or ...) right now, but it would be *great* to
> have
> >>>> going
> >>>>>>>> forward.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> cheers,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Leo
> >>>>>>>>
> >>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <runseb@gmail.com
> >
> >>>> wrote:
> >>>>>>>>
> >>>>>>>>> I would like to re-start this discussion.
> >>>>>>>>>
> >>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
> >>>>>>>>>
> >>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>
> >>>>>>>>> Thinking about our release procedure, we clearly need more tests
> and
> >>>> a
> >>>>>>>> CI. However it looks like this is going to take some time.
> >>>>>>>>>
> >>>>>>>>> In the meantime I think there is nothing preventing us from
> agreeing
> >>>> to
> >>>>>>>> 'git practices', we don't need tests or new infra, we just need to
> >>>> agree on
> >>>>>>>> the git workflow.
> >>>>>>>>>
> >>>>>>>>> Right now Master is really a development branch, we should make
> it a
> >>>>>>>> stable branch for production with very few commits.
> >>>>>>>>> This does not mean that we would release less, in contrary this
> would
> >>>>>>>> ensure that a commit to master means it's a production release.
> >>>>>>>>>
> >>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back to
> >>>> Rajani's
> >>>>>>>> point) everything is based on merges.
> >>>>>>>>>
> >>>>>>>>> I am of the opinion that git flow provides a nice process. It
> >>>> basically
> >>>>>>>> freezes master. Development happens in a 'develop' branch,
> releases
> >>>>>>>> branches are branched off of that and merged into master and back
> into
> >>>>>>>> develop….etc
> >>>>>>>>>
> >>>>>>>>> Please read [1] it's a good read.
> >>>>>>>>>
> >>>>>>>>> And let's discuss,
> >>>>>>>>>
> >>>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>
> >>>>>>>>> -Sebastien
> >>>>>>>>>
> >>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
> >>>> Rajani.Karuturi@citrix.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> There is also the problem of cherry-picking.
> >>>>>>>>>> As a contributor, I always endup creating multiple patches for
> each
> >>>>>>>> branch as they don’t cleanly apply on the upward branches. which
> means
> >>>>>>>> distinct commits for each branch and I don’t easily know which all
> >>>> branches
> >>>>>>>> my commit exists unless I do grep.
> >>>>>>>>>> if we follow merging strategy properly, apart from the first
> merge
> >>>> of
> >>>>>>>> the branch, everything else on top of it should be a painless
> merge.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ~Rajani
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com>
> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I think many of the bullet points are what we are currently
> doing
> >>>>>>>>>>> (guidelines for commit comments, feature branches need to stay
> in
> >>>> sync
> >>>>>>>> with
> >>>>>>>>>>> master, no back-merging). I also think that much of what we do
> now
> >>>> is
> >>>>>>>> done
> >>>>>>>>>>> the way it is simply because there *are* vast changes between
> >>>> versions.
> >>>>>>>>>>> Classes are getting shuffled around and changed all the time.
> If
> >>>> its
> >>>>>>>>>>> feasible to merge branch fixes to master, that's fine, but some
> >>>> quick
> >>>>>>>> tests
> >>>>>>>>>>> seem to indicate that this will be messy getting started.
> >>>>>>>>>>>
> >>>>>>>>>>> That leaves us with how we do releases. I'm fine with having
> single
> >>>>>>>>>>> branches for major releases(4.3) and tagging the commits where
> each
> >>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember
> why we
> >>>> went
> >>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
> somewhere, but
> >>>>>>>> one of
> >>>>>>>>>>> the nice things it provides is the ability for the release
> manager
> >>>> to
> >>>>>>>>>>> control what changes are made during code freeze while giving
> >>>> people a
> >>>>>>>>>>> place to stage fixes (though admittedly this is not always
> >>>> followed).
> >>>>>>>>>>> Without -forward, would the flow be for each dev to have their
> own
> >>>>>>>> repo and
> >>>>>>>>>>> issue pull requests for bugfixes?
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> >>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Any other suggestions/objections/comments??
> >>>>>>>>>>>> Can we discuss this in detail and agree to a process??
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> >>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
> >>>>>>>> merge(merge -s
> >>>>>>>>>>>> ours) for it and git will assume its merged but will not
> bring in
> >>>> any
> >>>>>>>>>>>> changes.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If the branches diverged a lot, for example after a major
> >>>> rewrite, we
> >>>>>>>>>>>> could stop merging to that branch and above and make the fix
> >>>> manually.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Yep, that's what I was referring to in that a particular fix
> >>>> for an
> >>>>>>>> old
> >>>>>>>>>>>>>> release may not apply to newer versions. That does happen.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> We used to mark those as "don't need to merge to branch x"
> in
> >>>> SVN
> >>>>>>>> and
> >>>>>>>>>>>> then
> >>>>>>>>>>>>>> you handed it however made sense on the applicable
> branch(es).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>>>>>>>>>>> Stephen.Turner@citrix.com>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
> >>>> has to
> >>>>>>>> be
> >>>>>>>>>>>>>>> rewritten for newer versions because the code has changed?
> >>>> Don't
> >>>>>>>> the
> >>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after that?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> Stephen Turner
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> >>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
> >>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
> >>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I think this flow is something we should seriously
> consider.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I find cherry picking from branch to branch to be error
> prone
> >>>> in
> >>>>>>>> that
> >>>>>>>>>>>> it's
> >>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
> >>>>>>>> branches
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
> >>>> related.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to see
> if you
> >>>>>>>>>>>> checked a
> >>>>>>>>>>>>>>> fix into a prior release, but not later releases. In such a
> >>>>>>>> situation,
> >>>>>>>>>>>> you
> >>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
> >>>> was no
> >>>>>>>>>>>> longer
> >>>>>>>>>>>>>>> applicable in the later release(s), so you needed to mark
> it as
> >>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure about
> Git).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Our current git workflow is confusing with the *forward
> >>>> branches
> >>>>>>>> and
> >>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
> >>>> commit
> >>>>>>>> has
> >>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
> >>>>>>>> contributor, I
> >>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
> cleanly
> >>>>>>>> apply on
> >>>>>>>>>>>>>>>> different branches.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
> >>>> propose.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1.  There should be branch for every major release(ex:
> 4.3.x,
> >>>>>>>> 4.4.x,
> >>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
> >>>> accordingly
> >>>>>>>> on
> >>>>>>>>>>>>>>>> the respective branches.
> >>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
> >>>> branches
> >>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
> >>>> cherry-pick,
> >>>>>>>>>>>>>>>> we have two physically distinct commits for the same
> change or
> >>>>>>>> fix and
> >>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>>>>>>>>>>> 4.  There should always be a continous flow from release
> >>>> branches
> >>>>>>>> to
> >>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
> >>>>>>>> merged(either
> >>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
> trackable
> >>>>>>>> with
> >>>>>>>>>>>>>>>> git branch --contains
> >>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal release
> >>>> uptill
> >>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
> >>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> >>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time a
> new
> >>>> commit
> >>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>> done this will also get merged.
> >>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from master
> to
> >>>>>>>> feature
> >>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
> proactively
> >>>>>>>> take
> >>>>>>>>>>>>>>>> any new commits from master by doing a merge from master
> >>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to master on
> >>>> code
> >>>>>>>>>>>>>>>> complete through a merge.
> >>>>>>>>>>>>>>>> 7.  There should never be a merge from master to release
> >>>> branches
> >>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor
> release)
> >>>>>>>>>>>>>>>> should have atleast bug id and correct author information
> >>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
> >>>>>>>>>>>> <committer>
> >>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
> >>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
> >>>> any bug
> >>>>>>>>>>>>>>>> in jira can be marked with fix version current
> release(4.4)
> >>>> only
> >>>>>>>> on
> >>>>>>>>>>>>>>>> RM's approval and only they can go to the release branch.
> >>>> This
> >>>>>>>> can be
> >>>>>>>>>>>>>>>> done through jira and with certain rules.(may be using
> jira
> >>>> vote?)
> >>>>>>>>>>>>>>>> this would save the cherry-picking time and another branch
> >>>>>>>>>>>> maintenance.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Ref:
> >>>>>>>>>>>>>>>>
> >>>>>>>>
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ~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>*™*
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> *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
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>>
> >>>
> >>> *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.
> >>
> >
>
>
>
> --
> 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: [DISCUSS][PROPOSAL] git workflow

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

so to start formulate a proposal:

all work shall be done in a new branch (it is advisable to prefix your
branches with your id)
when working, features will be cherry-picked/merged into the release
branch they are for and next into master.
hotfixes will be done in <branchname>-hotfixes

as transition we will

rename 'master' to 'develop'
branch a new 'master' from '4.4'
branch '4.5' from the new 'master'
merge any features from the new 'develop' to '4.5' and 'master'



On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
>>
>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com> wrote:
>>
>>> Let me ask the question, why have master be develop and a release branch be
>>> "master"? If we are going to follow gitflow, why not just stick with the
>>> norm? If master is the development branch, it might not be stable. I think
>>> the goal here is that we have an obvious stable branch. Anyone could come
>>> check out master and have the latest useable.
>>
>> I am in favor of following the norm, so ideally master should be our stable branch (agreed).
>>
>> The issue is with the transition.
>>
>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally we could start a stable branch of this tag and build up bug fix releases all the way to 4.5 from there.
>>
>> But all features for 4.5 are already in master.
>>
>> So if we create a 'develop' branch of master and stabilize 'master' then develop is now started from a stable tag (4.4.0).
>>
>
> *not* started from a stable tag, and merges will be tricky, no ?
>
>> So what's the best way to flip ? There is most likely some git magic that can we do.
>>
>>
>> The new git workflow and the transition process need to be part of a proposal that we get consensus on.
>>
>> getting there :)
>>
>> -seb
>>
>>>
>>> Also, I'm struggling to understand the benefit of cherry-pick. If you
>>> completely squash history, you lose a tremendous amount of context, which I
>>> use extensively to figure out why a bug is the way it is. Only knowing that
>>> the branch was merged at a given point in time doesn't give any context.
>>> Seeing the individual commit history of the branch helps to preserve the
>>> rationale for why the code was written the way it was. In theory if every
>>> change starts out as a branch (feature, hotfix, release), then why not just
>>> merge the branch once it is in a good and acceptable state?
>>>
>>> I also agree with Mike that this will have to be a transition over time. It
>>> will take some time to clean up master to the point where it can be
>>> considered a solid stable branch. Possibly as part of the 4.5 release.
>>>
>>>
>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <ru...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
>>>> wrote:
>>>>
>>>>> Sebastien,
>>>>>
>>>>> It seems we can do what you are calling for is creating a branch
>>>>> called 'release'. We can merge back into that branch from 4.4, master,
>>>>> 4.3. I would like to see people that want a feature or bug fix in a
>>>>> branch make a fork of that branch and when that fork is working do a
>>>>> cherry-pick. The -forward concept is now used for that but it is
>>>>> broken because more then for one piece of work there are commits on
>>>>> it. This caused me conflicts during the release. Especially painfull
>>>>> as not all was intended to get into the release. We can create this
>>>>> 'release' branch now on the basis of 4.4 and start pulling in changes.
>>>>
>>>> Yes, that's what I am thinking about too, so +1
>>>>
>>>> Our master would become the -develop- in gitflow terms
>>>> The release branch you mention would become the -master- in gitflow terms
>>>>
>>>> If we start now, indeed we can create 'release' from 4.4 release tag
>>>> (voted and shipped).
>>>>
>>>> That means that to create 4.5 we will need to merge features back into
>>>> 'release'. it might be messy because some of those features are already in
>>>> our current master.
>>>>
>>>> But all of this will keep 'release' clean (we can keep track of bugs and
>>>> features that are in it in CHANGES file etc..)
>>>>
>>>>
>>>>> There is a question of control. Do we allow all committers to manage
>>>>> the release? I am for that but can imagine not everybody is.
>>>>>
>>>>
>>>> At first I would say that only the RM can commit to 'release'. As we get
>>>> the CI in place  we could relax this and allow commits that pass the CI to
>>>> get into 'release', but right now I would vote for a tighter control of
>>>> 'release'.
>>>>
>>>>> rule number 1 will be: you are going to do something to the code, you
>>>>> start by creating a branch.
>>>>>
>>>>> right?
>>>>>
>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <ru...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
>>>> wrote:
>>>>>>
>>>>>>> Hey everyone,
>>>>>>>
>>>>>>> I've been a developer for a handful of years and have had my share of
>>>>>>> experience with different version control systems.  I've used (for
>>>> better
>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>>>>>>
>>>>>>> Each of these solutions offers their own unique set of features,
>>>> strengths
>>>>>>> and weaknesses.  As there are so many systems that are good at specific
>>>>>>> things, it seems best to use the features that the chosen system is
>>>> best at.
>>>>>>>
>>>>>>> Git is great at branching, merging and using that structure to
>>>> maintain and
>>>>>>> control how changes get into the primary branches.  Git tools even make
>>>>>>> this easy by integrating directly into the "Gitflow" to make branching
>>>> and
>>>>>>> merging that much easier.  It would seem counter-intuitive to NOT make
>>>> use
>>>>>>> of these built-in capabilities.
>>>>>>>
>>>>>>> In addition to that, I know that the current method of change
>>>> management is
>>>>>>> incredibly frustrating to work with, and works directly against the
>>>> way a
>>>>>>> typical Git user would expect it to be structured.  I should NEVER have
>>>>>>> problem compiling and running something on master.  I should not have
>>>>>>> problems building anything on a release branch.  A feature/bugfix
>>>> branch is
>>>>>>> where things can be, and often are, broken or unstable.  There have
>>>> been
>>>>>>> many times working in Cloudstack where I've had to search for a stable
>>>>>>> revision on master, and that's just plain wrong.
>>>>>>>
>>>>>>> I do realize that having this many developers working on so many
>>>> features
>>>>>>> and bugfixes will result in a large number of branches.  I don't
>>>> believe
>>>>>>> this is a good argument against using a branching method, though - I
>>>>>>> believe that the current system is even more confusing and difficult
>>>> to use.
>>>>>>>
>>>>>>> I could pontificate on change management quite a bit more, but my
>>>> opinion
>>>>>>> in summary would basically be:  use Git the way it was meant to be
>>>> used,
>>>>>>> and things will be better.  Just my two cents.
>>>>>>>
>>>>>>> Sam
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Sam, I think we are in agreement (at least with folks who responded to
>>>> this thread).
>>>>>> Or maybe I am not reading your mail right and you don't agree with Leo ?
>>>>>>
>>>>>> My own take and reason for calling for a change we are currently doing
>>>> things is mostly due to the way we release.
>>>>>>
>>>>>> I would like to see a stable master (and I think we are in agreement
>>>> with that).
>>>>>> That means that development should not happen on master and that every
>>>> commit that lands on master should be shippable.
>>>>>>
>>>>>> I personally have no issues with cherry-picking. So I would be fine
>>>> cherry picking from a hot-fix branch into master, to fix a bug.
>>>>>> The end result is that the next commit on master would still mean
>>>> master is shippable/releasable.
>>>>>>
>>>>>> If we agree with this basic concept. The question becomes how do we get
>>>> there, considering that master is now full of dev work and potential bug.
>>>>>> The only releasable product we have are on the 4.3, 4.4 and previous
>>>> release branches.
>>>>>>
>>>>>> Ideally, I would like to see master becomes 4.4. And work our way back,
>>>> merging the new features that are already in master into the new master
>>>> (based on 4.4).
>>>>>> This could be quite complicated but we need to do it (or something like
>>>> it).
>>>>>>
>>>>>> To move forward, we should make a proposal to the list and call for a
>>>> vote.
>>>>>>
>>>>>> Any takers to start a wiki page proposing a new git process and how we
>>>> could move to it (transition path) ?
>>>>>>
>>>>>>
>>>>>> -Sebastien
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>>>> LSimons@schubergphilis.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hey folks,
>>>>>>>>
>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and implement this?
>>>>>>>>
>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
>>>> committer so
>>>>>>>> its not that practical for me to volunteer!
>>>>>>>>
>>>>>>>> I wanted to point out atlassian’s description of gitflow
>>>>>>>>
>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>>>>>>
>>>>>>>> which might be easier to read.
>>>>>>>>
>>>>>>>> Similarly, the git-flow scripts that help out with implementing this
>>>> stuff
>>>>>>>>
>>>>>>>> https://github.com/nvie/gitflow
>>>>>>>>
>>>>>>>> they also describe the relationship between gitflow and dealing with
>>>>>>>> multiple remotes
>>>>>>>>
>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>>>>>>>>
>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in support for
>>>>>>>> git-flow
>>>>>>>>
>>>>>>>> http://www.sourcetreeapp.com/
>>>>>>>>
>>>>>>>> Because cloudstack currently is full of rebasing and squashing and
>>>>>>>> cherry-picking, you get very little benefit from a tree visualization
>>>> tool
>>>>>>>> (like this or gitk or ...) right now, but it would be *great* to have
>>>> going
>>>>>>>> forward.
>>>>>>>>
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>>
>>>>>>>>
>>>>>>>> Leo
>>>>>>>>
>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <ru...@gmail.com>
>>>> wrote:
>>>>>>>>
>>>>>>>>> I would like to re-start this discussion.
>>>>>>>>>
>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>>>>>>
>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>
>>>>>>>>> Thinking about our release procedure, we clearly need more tests and
>>>> a
>>>>>>>> CI. However it looks like this is going to take some time.
>>>>>>>>>
>>>>>>>>> In the meantime I think there is nothing preventing us from agreeing
>>>> to
>>>>>>>> 'git practices', we don't need tests or new infra, we just need to
>>>> agree on
>>>>>>>> the git workflow.
>>>>>>>>>
>>>>>>>>> Right now Master is really a development branch, we should make it a
>>>>>>>> stable branch for production with very few commits.
>>>>>>>>> This does not mean that we would release less, in contrary this would
>>>>>>>> ensure that a commit to master means it's a production release.
>>>>>>>>>
>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back to
>>>> Rajani's
>>>>>>>> point) everything is based on merges.
>>>>>>>>>
>>>>>>>>> I am of the opinion that git flow provides a nice process. It
>>>> basically
>>>>>>>> freezes master. Development happens in a 'develop' branch, releases
>>>>>>>> branches are branched off of that and merged into master and back into
>>>>>>>> develop….etc
>>>>>>>>>
>>>>>>>>> Please read [1] it's a good read.
>>>>>>>>>
>>>>>>>>> And let's discuss,
>>>>>>>>>
>>>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>
>>>>>>>>> -Sebastien
>>>>>>>>>
>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>>>> Rajani.Karuturi@citrix.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> There is also the problem of cherry-picking.
>>>>>>>>>> As a contributor, I always endup creating multiple patches for each
>>>>>>>> branch as they don’t cleanly apply on the upward branches. which means
>>>>>>>> distinct commits for each branch and I don’t easily know which all
>>>> branches
>>>>>>>> my commit exists unless I do grep.
>>>>>>>>>> if we follow merging strategy properly, apart from the first merge
>>>> of
>>>>>>>> the branch, everything else on top of it should be a painless merge.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ~Rajani
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I think many of the bullet points are what we are currently doing
>>>>>>>>>>> (guidelines for commit comments, feature branches need to stay in
>>>> sync
>>>>>>>> with
>>>>>>>>>>> master, no back-merging). I also think that much of what we do now
>>>> is
>>>>>>>> done
>>>>>>>>>>> the way it is simply because there *are* vast changes between
>>>> versions.
>>>>>>>>>>> Classes are getting shuffled around and changed all the time. If
>>>> its
>>>>>>>>>>> feasible to merge branch fixes to master, that's fine, but some
>>>> quick
>>>>>>>> tests
>>>>>>>>>>> seem to indicate that this will be messy getting started.
>>>>>>>>>>>
>>>>>>>>>>> That leaves us with how we do releases. I'm fine with having single
>>>>>>>>>>> branches for major releases(4.3) and tagging the commits where each
>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember why we
>>>> went
>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list somewhere, but
>>>>>>>> one of
>>>>>>>>>>> the nice things it provides is the ability for the release manager
>>>> to
>>>>>>>>>>> control what changes are made during code freeze while giving
>>>> people a
>>>>>>>>>>> place to stage fixes (though admittedly this is not always
>>>> followed).
>>>>>>>>>>> Without -forward, would the flow be for each dev to have their own
>>>>>>>> repo and
>>>>>>>>>>> issue pull requests for bugfixes?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Any other suggestions/objections/comments??
>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>>>>>>>> merge(merge -s
>>>>>>>>>>>> ours) for it and git will assume its merged but will not bring in
>>>> any
>>>>>>>>>>>> changes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the branches diverged a lot, for example after a major
>>>> rewrite, we
>>>>>>>>>>>> could stop merging to that branch and above and make the fix
>>>> manually.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yep, that's what I was referring to in that a particular fix
>>>> for an
>>>>>>>> old
>>>>>>>>>>>>>> release may not apply to newer versions. That does happen.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We used to mark those as "don't need to merge to branch x" in
>>>> SVN
>>>>>>>> and
>>>>>>>>>>>> then
>>>>>>>>>>>>>> you handed it however made sense on the applicable branch(es).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
>>>> has to
>>>>>>>> be
>>>>>>>>>>>>>>> rewritten for newer versions because the code has changed?
>>>> Don't
>>>>>>>> the
>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Stephen Turner
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think this flow is something we should seriously consider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be error prone
>>>> in
>>>>>>>> that
>>>>>>>>>>>> it's
>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
>>>>>>>> branches
>>>>>>>>>>>> and
>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
>>>> related.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to see if you
>>>>>>>>>>>> checked a
>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In such a
>>>>>>>> situation,
>>>>>>>>>>>> you
>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
>>>> was no
>>>>>>>>>>>> longer
>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to mark it as
>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure about Git).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Our current git workflow is confusing with the *forward
>>>> branches
>>>>>>>> and
>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
>>>> commit
>>>>>>>> has
>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>>>>>>>> contributor, I
>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t cleanly
>>>>>>>> apply on
>>>>>>>>>>>>>>>> different branches.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
>>>> propose.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
>>>>>>>> 4.4.x,
>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>>>> accordingly
>>>>>>>> on
>>>>>>>>>>>>>>>> the respective branches.
>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
>>>> branches
>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
>>>> cherry-pick,
>>>>>>>>>>>>>>>> we have two physically distinct commits for the same change or
>>>>>>>> fix and
>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from release
>>>> branches
>>>>>>>> to
>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
>>>>>>>> merged(either
>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable
>>>>>>>> with
>>>>>>>>>>>>>>>> git branch --contains
>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal release
>>>> uptill
>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time a new
>>>> commit
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from master to
>>>>>>>> feature
>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should proactively
>>>>>>>> take
>>>>>>>>>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to master on
>>>> code
>>>>>>>>>>>>>>>> complete through a merge.
>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to release
>>>> branches
>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>>>>>>>>>>>>>>>> should have atleast bug id and correct author information
>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>>>>>>>>>>>> <committer>
>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
>>>> any bug
>>>>>>>>>>>>>>>> in jira can be marked with fix version current release(4.4)
>>>> only
>>>>>>>> on
>>>>>>>>>>>>>>>> RM's approval and only they can go to the release branch.
>>>> This
>>>>>>>> can be
>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be using jira
>>>> vote?)
>>>>>>>>>>>>>>>> this would save the cherry-picking time and another branch
>>>>>>>>>>>> maintenance.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ref:
>>>>>>>>>>>>>>>>
>>>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ~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>*™*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> *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
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>> *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.
>>
>



-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

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

On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <ru...@gmail.com> wrote:

> 
> On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com> wrote:
> 
>> Let me ask the question, why have master be develop and a release branch be
>> "master"? If we are going to follow gitflow, why not just stick with the
>> norm? If master is the development branch, it might not be stable. I think
>> the goal here is that we have an obvious stable branch. Anyone could come
>> check out master and have the latest useable.
> 
> I am in favor of following the norm, so ideally master should be our stable branch (agreed).
> 
> The issue is with the transition.
> 
> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally we could start a stable branch of this tag and build up bug fix releases all the way to 4.5 from there.
> 
> But all features for 4.5 are already in master.
> 
> So if we create a 'develop' branch of master and stabilize 'master' then develop is now started from a stable tag (4.4.0).
> 

*not* started from a stable tag, and merges will be tricky, no ?

> So what's the best way to flip ? There is most likely some git magic that can we do.
> 
> 
> The new git workflow and the transition process need to be part of a proposal that we get consensus on.
> 
> getting there :)
> 
> -seb
> 
>> 
>> Also, I'm struggling to understand the benefit of cherry-pick. If you
>> completely squash history, you lose a tremendous amount of context, which I
>> use extensively to figure out why a bug is the way it is. Only knowing that
>> the branch was merged at a given point in time doesn't give any context.
>> Seeing the individual commit history of the branch helps to preserve the
>> rationale for why the code was written the way it was. In theory if every
>> change starts out as a branch (feature, hotfix, release), then why not just
>> merge the branch once it is in a good and acceptable state?
>> 
>> I also agree with Mike that this will have to be a transition over time. It
>> will take some time to clean up master to the point where it can be
>> considered a solid stable branch. Possibly as part of the 4.5 release.
>> 
>> 
>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>> 
>>> 
>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
>>> wrote:
>>> 
>>>> Sebastien,
>>>> 
>>>> It seems we can do what you are calling for is creating a branch
>>>> called 'release'. We can merge back into that branch from 4.4, master,
>>>> 4.3. I would like to see people that want a feature or bug fix in a
>>>> branch make a fork of that branch and when that fork is working do a
>>>> cherry-pick. The -forward concept is now used for that but it is
>>>> broken because more then for one piece of work there are commits on
>>>> it. This caused me conflicts during the release. Especially painfull
>>>> as not all was intended to get into the release. We can create this
>>>> 'release' branch now on the basis of 4.4 and start pulling in changes.
>>> 
>>> Yes, that's what I am thinking about too, so +1
>>> 
>>> Our master would become the -develop- in gitflow terms
>>> The release branch you mention would become the -master- in gitflow terms
>>> 
>>> If we start now, indeed we can create 'release' from 4.4 release tag
>>> (voted and shipped).
>>> 
>>> That means that to create 4.5 we will need to merge features back into
>>> 'release'. it might be messy because some of those features are already in
>>> our current master.
>>> 
>>> But all of this will keep 'release' clean (we can keep track of bugs and
>>> features that are in it in CHANGES file etc..)
>>> 
>>> 
>>>> There is a question of control. Do we allow all committers to manage
>>>> the release? I am for that but can imagine not everybody is.
>>>> 
>>> 
>>> At first I would say that only the RM can commit to 'release'. As we get
>>> the CI in place  we could relax this and allow commits that pass the CI to
>>> get into 'release', but right now I would vote for a tighter control of
>>> 'release'.
>>> 
>>>> rule number 1 will be: you are going to do something to the code, you
>>>> start by creating a branch.
>>>> 
>>>> right?
>>>> 
>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <ru...@gmail.com>
>>> wrote:
>>>>> 
>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
>>> wrote:
>>>>> 
>>>>>> Hey everyone,
>>>>>> 
>>>>>> I've been a developer for a handful of years and have had my share of
>>>>>> experience with different version control systems.  I've used (for
>>> better
>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>>>>> 
>>>>>> Each of these solutions offers their own unique set of features,
>>> strengths
>>>>>> and weaknesses.  As there are so many systems that are good at specific
>>>>>> things, it seems best to use the features that the chosen system is
>>> best at.
>>>>>> 
>>>>>> Git is great at branching, merging and using that structure to
>>> maintain and
>>>>>> control how changes get into the primary branches.  Git tools even make
>>>>>> this easy by integrating directly into the "Gitflow" to make branching
>>> and
>>>>>> merging that much easier.  It would seem counter-intuitive to NOT make
>>> use
>>>>>> of these built-in capabilities.
>>>>>> 
>>>>>> In addition to that, I know that the current method of change
>>> management is
>>>>>> incredibly frustrating to work with, and works directly against the
>>> way a
>>>>>> typical Git user would expect it to be structured.  I should NEVER have
>>>>>> problem compiling and running something on master.  I should not have
>>>>>> problems building anything on a release branch.  A feature/bugfix
>>> branch is
>>>>>> where things can be, and often are, broken or unstable.  There have
>>> been
>>>>>> many times working in Cloudstack where I've had to search for a stable
>>>>>> revision on master, and that's just plain wrong.
>>>>>> 
>>>>>> I do realize that having this many developers working on so many
>>> features
>>>>>> and bugfixes will result in a large number of branches.  I don't
>>> believe
>>>>>> this is a good argument against using a branching method, though - I
>>>>>> believe that the current system is even more confusing and difficult
>>> to use.
>>>>>> 
>>>>>> I could pontificate on change management quite a bit more, but my
>>> opinion
>>>>>> in summary would basically be:  use Git the way it was meant to be
>>> used,
>>>>>> and things will be better.  Just my two cents.
>>>>>> 
>>>>>> Sam
>>>>>> 
>>>>>> 
>>>>> 
>>>>> Sam, I think we are in agreement (at least with folks who responded to
>>> this thread).
>>>>> Or maybe I am not reading your mail right and you don't agree with Leo ?
>>>>> 
>>>>> My own take and reason for calling for a change we are currently doing
>>> things is mostly due to the way we release.
>>>>> 
>>>>> I would like to see a stable master (and I think we are in agreement
>>> with that).
>>>>> That means that development should not happen on master and that every
>>> commit that lands on master should be shippable.
>>>>> 
>>>>> I personally have no issues with cherry-picking. So I would be fine
>>> cherry picking from a hot-fix branch into master, to fix a bug.
>>>>> The end result is that the next commit on master would still mean
>>> master is shippable/releasable.
>>>>> 
>>>>> If we agree with this basic concept. The question becomes how do we get
>>> there, considering that master is now full of dev work and potential bug.
>>>>> The only releasable product we have are on the 4.3, 4.4 and previous
>>> release branches.
>>>>> 
>>>>> Ideally, I would like to see master becomes 4.4. And work our way back,
>>> merging the new features that are already in master into the new master
>>> (based on 4.4).
>>>>> This could be quite complicated but we need to do it (or something like
>>> it).
>>>>> 
>>>>> To move forward, we should make a proposal to the list and call for a
>>> vote.
>>>>> 
>>>>> Any takers to start a wiki page proposing a new git process and how we
>>> could move to it (transition path) ?
>>>>> 
>>>>> 
>>>>> -Sebastien
>>>>> 
>>>>> 
>>>>>> 
>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>>> LSimons@schubergphilis.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Hey folks,
>>>>>>> 
>>>>>>> With 4.4.0 tagged, is now an opportune time to go and implement this?
>>>>>>> 
>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
>>> committer so
>>>>>>> its not that practical for me to volunteer!
>>>>>>> 
>>>>>>> I wanted to point out atlassian’s description of gitflow
>>>>>>> 
>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>>>>> 
>>>>>>> which might be easier to read.
>>>>>>> 
>>>>>>> Similarly, the git-flow scripts that help out with implementing this
>>> stuff
>>>>>>> 
>>>>>>> https://github.com/nvie/gitflow
>>>>>>> 
>>>>>>> they also describe the relationship between gitflow and dealing with
>>>>>>> multiple remotes
>>>>>>> 
>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>>>>>>> 
>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in support for
>>>>>>> git-flow
>>>>>>> 
>>>>>>> http://www.sourcetreeapp.com/
>>>>>>> 
>>>>>>> Because cloudstack currently is full of rebasing and squashing and
>>>>>>> cherry-picking, you get very little benefit from a tree visualization
>>> tool
>>>>>>> (like this or gitk or ...) right now, but it would be *great* to have
>>> going
>>>>>>> forward.
>>>>>>> 
>>>>>>> 
>>>>>>> cheers,
>>>>>>> 
>>>>>>> 
>>>>>>> Leo
>>>>>>> 
>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <ru...@gmail.com>
>>> wrote:
>>>>>>> 
>>>>>>>> I would like to re-start this discussion.
>>>>>>>> 
>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>>>>> 
>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>> 
>>>>>>>> Thinking about our release procedure, we clearly need more tests and
>>> a
>>>>>>> CI. However it looks like this is going to take some time.
>>>>>>>> 
>>>>>>>> In the meantime I think there is nothing preventing us from agreeing
>>> to
>>>>>>> 'git practices', we don't need tests or new infra, we just need to
>>> agree on
>>>>>>> the git workflow.
>>>>>>>> 
>>>>>>>> Right now Master is really a development branch, we should make it a
>>>>>>> stable branch for production with very few commits.
>>>>>>>> This does not mean that we would release less, in contrary this would
>>>>>>> ensure that a commit to master means it's a production release.
>>>>>>>> 
>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back to
>>> Rajani's
>>>>>>> point) everything is based on merges.
>>>>>>>> 
>>>>>>>> I am of the opinion that git flow provides a nice process. It
>>> basically
>>>>>>> freezes master. Development happens in a 'develop' branch, releases
>>>>>>> branches are branched off of that and merged into master and back into
>>>>>>> develop….etc
>>>>>>>> 
>>>>>>>> Please read [1] it's a good read.
>>>>>>>> 
>>>>>>>> And let's discuss,
>>>>>>>> 
>>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>> 
>>>>>>>> -Sebastien
>>>>>>>> 
>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>>> Rajani.Karuturi@citrix.com>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> There is also the problem of cherry-picking.
>>>>>>>>> As a contributor, I always endup creating multiple patches for each
>>>>>>> branch as they don’t cleanly apply on the upward branches. which means
>>>>>>> distinct commits for each branch and I don’t easily know which all
>>> branches
>>>>>>> my commit exists unless I do grep.
>>>>>>>>> if we follow merging strategy properly, apart from the first merge
>>> of
>>>>>>> the branch, everything else on top of it should be a painless merge.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ~Rajani
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>>> I think many of the bullet points are what we are currently doing
>>>>>>>>>> (guidelines for commit comments, feature branches need to stay in
>>> sync
>>>>>>> with
>>>>>>>>>> master, no back-merging). I also think that much of what we do now
>>> is
>>>>>>> done
>>>>>>>>>> the way it is simply because there *are* vast changes between
>>> versions.
>>>>>>>>>> Classes are getting shuffled around and changed all the time. If
>>> its
>>>>>>>>>> feasible to merge branch fixes to master, that's fine, but some
>>> quick
>>>>>>> tests
>>>>>>>>>> seem to indicate that this will be messy getting started.
>>>>>>>>>> 
>>>>>>>>>> That leaves us with how we do releases. I'm fine with having single
>>>>>>>>>> branches for major releases(4.3) and tagging the commits where each
>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember why we
>>> went
>>>>>>>>>> with the -forward, I'm sure it's in the mailing list somewhere, but
>>>>>>> one of
>>>>>>>>>> the nice things it provides is the ability for the release manager
>>> to
>>>>>>>>>> control what changes are made during code freeze while giving
>>> people a
>>>>>>>>>> place to stage fixes (though admittedly this is not always
>>> followed).
>>>>>>>>>> Without -forward, would the flow be for each dev to have their own
>>>>>>> repo and
>>>>>>>>>> issue pull requests for bugfixes?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Any other suggestions/objections/comments??
>>>>>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> ~Rajani
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>>>>>>> merge(merge -s
>>>>>>>>>>> ours) for it and git will assume its merged but will not bring in
>>> any
>>>>>>>>>>> changes.
>>>>>>>>>>>> 
>>>>>>>>>>>> If the branches diverged a lot, for example after a major
>>> rewrite, we
>>>>>>>>>>> could stop merging to that branch and above and make the fix
>>> manually.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Yep, that's what I was referring to in that a particular fix
>>> for an
>>>>>>> old
>>>>>>>>>>>>> release may not apply to newer versions. That does happen.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> We used to mark those as "don't need to merge to branch x" in
>>> SVN
>>>>>>> and
>>>>>>>>>>> then
>>>>>>>>>>>>> you handed it however made sense on the applicable branch(es).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
>>> has to
>>>>>>> be
>>>>>>>>>>>>>> rewritten for newer versions because the code has changed?
>>> Don't
>>>>>>> the
>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Stephen Turner
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I think this flow is something we should seriously consider.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I find cherry picking from branch to branch to be error prone
>>> in
>>>>>>> that
>>>>>>>>>>> it's
>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
>>>>>>> branches
>>>>>>>>>>> and
>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
>>> related.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to see if you
>>>>>>>>>>> checked a
>>>>>>>>>>>>>> fix into a prior release, but not later releases. In such a
>>>>>>> situation,
>>>>>>>>>>> you
>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
>>> was no
>>>>>>>>>>> longer
>>>>>>>>>>>>>> applicable in the later release(s), so you needed to mark it as
>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure about Git).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Our current git workflow is confusing with the *forward
>>> branches
>>>>>>> and
>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
>>> commit
>>>>>>> has
>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>>>>>>> contributor, I
>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t cleanly
>>>>>>> apply on
>>>>>>>>>>>>>>> different branches.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
>>> propose.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
>>>>>>> 4.4.x,
>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>>> accordingly
>>>>>>> on
>>>>>>>>>>>>>>> the respective branches.
>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
>>> branches
>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
>>> cherry-pick,
>>>>>>>>>>>>>>> we have two physically distinct commits for the same change or
>>>>>>> fix and
>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>>>>>>> 4.  There should always be a continous flow from release
>>> branches
>>>>>>> to
>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
>>>>>>> merged(either
>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable
>>>>>>> with
>>>>>>>>>>>>>>> git branch --contains
>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal release
>>> uptill
>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time a new
>>> commit
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from master to
>>>>>>> feature
>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should proactively
>>>>>>> take
>>>>>>>>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to master on
>>> code
>>>>>>>>>>>>>>> complete through a merge.
>>>>>>>>>>>>>>> 7.  There should never be a merge from master to release
>>> branches
>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>>>>>>>>>>>>>>> should have atleast bug id and correct author information
>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>>>>>>>>>>> <committer>
>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
>>> any bug
>>>>>>>>>>>>>>> in jira can be marked with fix version current release(4.4)
>>> only
>>>>>>> on
>>>>>>>>>>>>>>> RM's approval and only they can go to the release branch.
>>> This
>>>>>>> can be
>>>>>>>>>>>>>>> done through jira and with certain rules.(may be using jira
>>> vote?)
>>>>>>>>>>>>>>> this would save the cherry-picking time and another branch
>>>>>>>>>>> maintenance.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Ref:
>>>>>>>>>>>>>>> 
>>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> ~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>*™*
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *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
>>> 
>>> 
>> 
>> 
>> -- 
>> 
>> 
>> *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: [DISCUSS][PROPOSAL] git workflow

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

On Jul 23, 2014, at 12:21 PM, Nate Gordon <na...@appcore.com> wrote:

> Let me ask the question, why have master be develop and a release branch be
> "master"? If we are going to follow gitflow, why not just stick with the
> norm? If master is the development branch, it might not be stable. I think
> the goal here is that we have an obvious stable branch. Anyone could come
> check out master and have the latest useable.

I am in favor of following the norm, so ideally master should be our stable branch (agreed).

The issue is with the transition.

Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally we could start a stable branch of this tag and build up bug fix releases all the way to 4.5 from there.

But all features for 4.5 are already in master.

So if we create a 'develop' branch of master and stabilize 'master' then develop is now started from a stable tag (4.4.0).

So what's the best way to flip ? There is most likely some git magic that can we do.


The new git workflow and the transition process need to be part of a proposal that we get consensus on.

getting there :)

-seb

> 
> Also, I'm struggling to understand the benefit of cherry-pick. If you
> completely squash history, you lose a tremendous amount of context, which I
> use extensively to figure out why a bug is the way it is. Only knowing that
> the branch was merged at a given point in time doesn't give any context.
> Seeing the individual commit history of the branch helps to preserve the
> rationale for why the code was written the way it was. In theory if every
> change starts out as a branch (feature, hotfix, release), then why not just
> merge the branch once it is in a good and acceptable state?
> 
> I also agree with Mike that this will have to be a transition over time. It
> will take some time to clean up master to the point where it can be
> considered a solid stable branch. Possibly as part of the 4.5 release.
> 
> 
> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> 
>> 
>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
>> wrote:
>> 
>>> Sebastien,
>>> 
>>> It seems we can do what you are calling for is creating a branch
>>> called 'release'. We can merge back into that branch from 4.4, master,
>>> 4.3. I would like to see people that want a feature or bug fix in a
>>> branch make a fork of that branch and when that fork is working do a
>>> cherry-pick. The -forward concept is now used for that but it is
>>> broken because more then for one piece of work there are commits on
>>> it. This caused me conflicts during the release. Especially painfull
>>> as not all was intended to get into the release. We can create this
>>> 'release' branch now on the basis of 4.4 and start pulling in changes.
>> 
>> Yes, that's what I am thinking about too, so +1
>> 
>> Our master would become the -develop- in gitflow terms
>> The release branch you mention would become the -master- in gitflow terms
>> 
>> If we start now, indeed we can create 'release' from 4.4 release tag
>> (voted and shipped).
>> 
>> That means that to create 4.5 we will need to merge features back into
>> 'release'. it might be messy because some of those features are already in
>> our current master.
>> 
>> But all of this will keep 'release' clean (we can keep track of bugs and
>> features that are in it in CHANGES file etc..)
>> 
>> 
>>> There is a question of control. Do we allow all committers to manage
>>> the release? I am for that but can imagine not everybody is.
>>> 
>> 
>> At first I would say that only the RM can commit to 'release'. As we get
>> the CI in place  we could relax this and allow commits that pass the CI to
>> get into 'release', but right now I would vote for a tighter control of
>> 'release'.
>> 
>>> rule number 1 will be: you are going to do something to the code, you
>>> start by creating a branch.
>>> 
>>> right?
>>> 
>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>>>> 
>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
>> wrote:
>>>> 
>>>>> Hey everyone,
>>>>> 
>>>>> I've been a developer for a handful of years and have had my share of
>>>>> experience with different version control systems.  I've used (for
>> better
>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>>>> 
>>>>> Each of these solutions offers their own unique set of features,
>> strengths
>>>>> and weaknesses.  As there are so many systems that are good at specific
>>>>> things, it seems best to use the features that the chosen system is
>> best at.
>>>>> 
>>>>> Git is great at branching, merging and using that structure to
>> maintain and
>>>>> control how changes get into the primary branches.  Git tools even make
>>>>> this easy by integrating directly into the "Gitflow" to make branching
>> and
>>>>> merging that much easier.  It would seem counter-intuitive to NOT make
>> use
>>>>> of these built-in capabilities.
>>>>> 
>>>>> In addition to that, I know that the current method of change
>> management is
>>>>> incredibly frustrating to work with, and works directly against the
>> way a
>>>>> typical Git user would expect it to be structured.  I should NEVER have
>>>>> problem compiling and running something on master.  I should not have
>>>>> problems building anything on a release branch.  A feature/bugfix
>> branch is
>>>>> where things can be, and often are, broken or unstable.  There have
>> been
>>>>> many times working in Cloudstack where I've had to search for a stable
>>>>> revision on master, and that's just plain wrong.
>>>>> 
>>>>> I do realize that having this many developers working on so many
>> features
>>>>> and bugfixes will result in a large number of branches.  I don't
>> believe
>>>>> this is a good argument against using a branching method, though - I
>>>>> believe that the current system is even more confusing and difficult
>> to use.
>>>>> 
>>>>> I could pontificate on change management quite a bit more, but my
>> opinion
>>>>> in summary would basically be:  use Git the way it was meant to be
>> used,
>>>>> and things will be better.  Just my two cents.
>>>>> 
>>>>> Sam
>>>>> 
>>>>> 
>>>> 
>>>> Sam, I think we are in agreement (at least with folks who responded to
>> this thread).
>>>> Or maybe I am not reading your mail right and you don't agree with Leo ?
>>>> 
>>>> My own take and reason for calling for a change we are currently doing
>> things is mostly due to the way we release.
>>>> 
>>>> I would like to see a stable master (and I think we are in agreement
>> with that).
>>>> That means that development should not happen on master and that every
>> commit that lands on master should be shippable.
>>>> 
>>>> I personally have no issues with cherry-picking. So I would be fine
>> cherry picking from a hot-fix branch into master, to fix a bug.
>>>> The end result is that the next commit on master would still mean
>> master is shippable/releasable.
>>>> 
>>>> If we agree with this basic concept. The question becomes how do we get
>> there, considering that master is now full of dev work and potential bug.
>>>> The only releasable product we have are on the 4.3, 4.4 and previous
>> release branches.
>>>> 
>>>> Ideally, I would like to see master becomes 4.4. And work our way back,
>> merging the new features that are already in master into the new master
>> (based on 4.4).
>>>> This could be quite complicated but we need to do it (or something like
>> it).
>>>> 
>>>> To move forward, we should make a proposal to the list and call for a
>> vote.
>>>> 
>>>> Any takers to start a wiki page proposing a new git process and how we
>> could move to it (transition path) ?
>>>> 
>>>> 
>>>> -Sebastien
>>>> 
>>>> 
>>>>> 
>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>> LSimons@schubergphilis.com>
>>>>> wrote:
>>>>> 
>>>>>> Hey folks,
>>>>>> 
>>>>>> With 4.4.0 tagged, is now an opportune time to go and implement this?
>>>>>> 
>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
>> committer so
>>>>>> its not that practical for me to volunteer!
>>>>>> 
>>>>>> I wanted to point out atlassian’s description of gitflow
>>>>>> 
>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>>>> 
>>>>>> which might be easier to read.
>>>>>> 
>>>>>> Similarly, the git-flow scripts that help out with implementing this
>> stuff
>>>>>> 
>>>>>> https://github.com/nvie/gitflow
>>>>>> 
>>>>>> they also describe the relationship between gitflow and dealing with
>>>>>> multiple remotes
>>>>>> 
>>>>>> https://www.atlassian.com/git/workflows#!pull-request
>>>>>> 
>>>>>> Finally note atlassian’s free sourcetree GUI has built-in support for
>>>>>> git-flow
>>>>>> 
>>>>>> http://www.sourcetreeapp.com/
>>>>>> 
>>>>>> Because cloudstack currently is full of rebasing and squashing and
>>>>>> cherry-picking, you get very little benefit from a tree visualization
>> tool
>>>>>> (like this or gitk or ...) right now, but it would be *great* to have
>> going
>>>>>> forward.
>>>>>> 
>>>>>> 
>>>>>> cheers,
>>>>>> 
>>>>>> 
>>>>>> Leo
>>>>>> 
>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>>>>>> 
>>>>>>> I would like to re-start this discussion.
>>>>>>> 
>>>>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>>>> 
>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>> 
>>>>>>> Thinking about our release procedure, we clearly need more tests and
>> a
>>>>>> CI. However it looks like this is going to take some time.
>>>>>>> 
>>>>>>> In the meantime I think there is nothing preventing us from agreeing
>> to
>>>>>> 'git practices', we don't need tests or new infra, we just need to
>> agree on
>>>>>> the git workflow.
>>>>>>> 
>>>>>>> Right now Master is really a development branch, we should make it a
>>>>>> stable branch for production with very few commits.
>>>>>>> This does not mean that we would release less, in contrary this would
>>>>>> ensure that a commit to master means it's a production release.
>>>>>>> 
>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back to
>> Rajani's
>>>>>> point) everything is based on merges.
>>>>>>> 
>>>>>>> I am of the opinion that git flow provides a nice process. It
>> basically
>>>>>> freezes master. Development happens in a 'develop' branch, releases
>>>>>> branches are branched off of that and merged into master and back into
>>>>>> develop….etc
>>>>>>> 
>>>>>>> Please read [1] it's a good read.
>>>>>>> 
>>>>>>> And let's discuss,
>>>>>>> 
>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>> 
>>>>>>> -Sebastien
>>>>>>> 
>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>> Rajani.Karuturi@citrix.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> There is also the problem of cherry-picking.
>>>>>>>> As a contributor, I always endup creating multiple patches for each
>>>>>> branch as they don’t cleanly apply on the upward branches. which means
>>>>>> distinct commits for each branch and I don’t easily know which all
>> branches
>>>>>> my commit exists unless I do grep.
>>>>>>>> if we follow merging strategy properly, apart from the first merge
>> of
>>>>>> the branch, everything else on top of it should be a painless merge.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ~Rajani
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
>>>>>>>> 
>>>>>>>>> I think many of the bullet points are what we are currently doing
>>>>>>>>> (guidelines for commit comments, feature branches need to stay in
>> sync
>>>>>> with
>>>>>>>>> master, no back-merging). I also think that much of what we do now
>> is
>>>>>> done
>>>>>>>>> the way it is simply because there *are* vast changes between
>> versions.
>>>>>>>>> Classes are getting shuffled around and changed all the time. If
>> its
>>>>>>>>> feasible to merge branch fixes to master, that's fine, but some
>> quick
>>>>>> tests
>>>>>>>>> seem to indicate that this will be messy getting started.
>>>>>>>>> 
>>>>>>>>> That leaves us with how we do releases. I'm fine with having single
>>>>>>>>> branches for major releases(4.3) and tagging the commits where each
>>>>>>>>> incremental release (4.3.x) is done. I'm trying to remember why we
>> went
>>>>>>>>> with the -forward, I'm sure it's in the mailing list somewhere, but
>>>>>> one of
>>>>>>>>> the nice things it provides is the ability for the release manager
>> to
>>>>>>>>> control what changes are made during code freeze while giving
>> people a
>>>>>>>>> place to stage fixes (though admittedly this is not always
>> followed).
>>>>>>>>> Without -forward, would the flow be for each dev to have their own
>>>>>> repo and
>>>>>>>>> issue pull requests for bugfixes?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Any other suggestions/objections/comments??
>>>>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> ~Rajani
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>>>>> Rajani.Karuturi@citrix.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>>>>>> merge(merge -s
>>>>>>>>>> ours) for it and git will assume its merged but will not bring in
>> any
>>>>>>>>>> changes.
>>>>>>>>>>> 
>>>>>>>>>>> If the branches diverged a lot, for example after a major
>> rewrite, we
>>>>>>>>>> could stop merging to that branch and above and make the fix
>> manually.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> ~Rajani
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Yep, that's what I was referring to in that a particular fix
>> for an
>>>>>> old
>>>>>>>>>>>> release may not apply to newer versions. That does happen.
>>>>>>>>>>>> 
>>>>>>>>>>>> We used to mark those as "don't need to merge to branch x" in
>> SVN
>>>>>> and
>>>>>>>>>> then
>>>>>>>>>>>> you handed it however made sense on the applicable branch(es).
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
>> has to
>>>>>> be
>>>>>>>>>>>>> rewritten for newer versions because the code has changed?
>> Don't
>>>>>> the
>>>>>>>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Stephen Turner
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I think this flow is something we should seriously consider.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I find cherry picking from branch to branch to be error prone
>> in
>>>>>> that
>>>>>>>>>> it's
>>>>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
>>>>>> branches
>>>>>>>>>> and
>>>>>>>>>>>>> you don't have any easy way to see the cherry picks are
>> related.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> When I worked at HP, we had automated tools check to see if you
>>>>>>>>>> checked a
>>>>>>>>>>>>> fix into a prior release, but not later releases. In such a
>>>>>> situation,
>>>>>>>>>> you
>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
>> was no
>>>>>>>>>> longer
>>>>>>>>>>>>> applicable in the later release(s), so you needed to mark it as
>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure about Git).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Our current git workflow is confusing with the *forward
>> branches
>>>>>> and
>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
>> commit
>>>>>> has
>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>>>>>> contributor, I
>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t cleanly
>>>>>> apply on
>>>>>>>>>>>>>> different branches.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I think we should have some guidelines. Here is what I
>> propose.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
>>>>>> 4.4.x,
>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>> accordingly
>>>>>> on
>>>>>>>>>>>>>> the respective branches.
>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
>> branches
>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
>> cherry-pick,
>>>>>>>>>>>>>> we have two physically distinct commits for the same change or
>>>>>> fix and
>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>>>>>> 4.  There should always be a continous flow from release
>> branches
>>>>>> to
>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
>>>>>> merged(either
>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable
>>>>>> with
>>>>>>>>>>>>>> git branch --contains
>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal release
>> uptill
>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next time a new
>> commit
>>>>>>>>>>>>> is
>>>>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>>>>> 5.  There should always be a continuous flow from master to
>>>>>> feature
>>>>>>>>>>>>>> branches. Meaning all feature branch owners should proactively
>>>>>> take
>>>>>>>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>>>>>>>> 6.  The commits from feature branch will make to master on
>> code
>>>>>>>>>>>>>> complete through a merge.
>>>>>>>>>>>>>> 7.  There should never be a merge from master to release
>> branches
>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>>>>>>>>>>>>>> should have atleast bug id and correct author information
>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>>>>>>>>>> <committer>
>>>>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
>> any bug
>>>>>>>>>>>>>> in jira can be marked with fix version current release(4.4)
>> only
>>>>>> on
>>>>>>>>>>>>>> RM's approval and only they can go to the release branch.
>> This
>>>>>> can be
>>>>>>>>>>>>>> done through jira and with certain rules.(may be using jira
>> vote?)
>>>>>>>>>>>>>> this would save the cherry-picking time and another branch
>>>>>>>>>> maintenance.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Ref:
>>>>>>>>>>>>>> 
>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ~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>*™*
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> *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
>> 
>> 
> 
> 
> -- 
> 
> 
> *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: [DISCUSS][PROPOSAL] git workflow

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

Let me ask the question, why have master be develop and a release branch be
"master"? If we are going to follow gitflow, why not just stick with the
norm? If master is the development branch, it might not be stable. I think
the goal here is that we have an obvious stable branch. Anyone could come
check out master and have the latest useable.

Also, I'm struggling to understand the benefit of cherry-pick. If you
completely squash history, you lose a tremendous amount of context, which I
use extensively to figure out why a bug is the way it is. Only knowing that
the branch was merged at a given point in time doesn't give any context.
Seeing the individual commit history of the branch helps to preserve the
rationale for why the code was written the way it was. In theory if every
change starts out as a branch (feature, hotfix, release), then why not just
merge the branch once it is in a good and acceptable state?

I also agree with Mike that this will have to be a transition over time. It
will take some time to clean up master to the point where it can be
considered a solid stable branch. Possibly as part of the 4.5 release.


On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <ru...@gmail.com>
wrote:

>
> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
> wrote:
>
> > Sebastien,
> >
> > It seems we can do what you are calling for is creating a branch
> > called 'release'. We can merge back into that branch from 4.4, master,
> > 4.3. I would like to see people that want a feature or bug fix in a
> > branch make a fork of that branch and when that fork is working do a
> > cherry-pick. The -forward concept is now used for that but it is
> > broken because more then for one piece of work there are commits on
> > it. This caused me conflicts during the release. Especially painfull
> > as not all was intended to get into the release. We can create this
> > 'release' branch now on the basis of 4.4 and start pulling in changes.
>
> Yes, that's what I am thinking about too, so +1
>
> Our master would become the -develop- in gitflow terms
> The release branch you mention would become the -master- in gitflow terms
>
> If we start now, indeed we can create 'release' from 4.4 release tag
> (voted and shipped).
>
> That means that to create 4.5 we will need to merge features back into
> 'release'. it might be messy because some of those features are already in
> our current master.
>
> But all of this will keep 'release' clean (we can keep track of bugs and
> features that are in it in CHANGES file etc..)
>
>
> > There is a question of control. Do we allow all committers to manage
> > the release? I am for that but can imagine not everybody is.
> >
>
> At first I would say that only the RM can commit to 'release'. As we get
> the CI in place  we could relax this and allow commits that pass the CI to
> get into 'release', but right now I would vote for a tighter control of
> 'release'.
>
> > rule number 1 will be: you are going to do something to the code, you
> > start by creating a branch.
> >
> > right?
> >
> > On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> >>
> >> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
> wrote:
> >>
> >>> Hey everyone,
> >>>
> >>> I've been a developer for a handful of years and have had my share of
> >>> experience with different version control systems.  I've used (for
> better
> >>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>
> >>> Each of these solutions offers their own unique set of features,
> strengths
> >>> and weaknesses.  As there are so many systems that are good at specific
> >>> things, it seems best to use the features that the chosen system is
> best at.
> >>>
> >>> Git is great at branching, merging and using that structure to
> maintain and
> >>> control how changes get into the primary branches.  Git tools even make
> >>> this easy by integrating directly into the "Gitflow" to make branching
> and
> >>> merging that much easier.  It would seem counter-intuitive to NOT make
> use
> >>> of these built-in capabilities.
> >>>
> >>> In addition to that, I know that the current method of change
> management is
> >>> incredibly frustrating to work with, and works directly against the
> way a
> >>> typical Git user would expect it to be structured.  I should NEVER have
> >>> problem compiling and running something on master.  I should not have
> >>> problems building anything on a release branch.  A feature/bugfix
> branch is
> >>> where things can be, and often are, broken or unstable.  There have
> been
> >>> many times working in Cloudstack where I've had to search for a stable
> >>> revision on master, and that's just plain wrong.
> >>>
> >>> I do realize that having this many developers working on so many
> features
> >>> and bugfixes will result in a large number of branches.  I don't
> believe
> >>> this is a good argument against using a branching method, though - I
> >>> believe that the current system is even more confusing and difficult
> to use.
> >>>
> >>> I could pontificate on change management quite a bit more, but my
> opinion
> >>> in summary would basically be:  use Git the way it was meant to be
> used,
> >>> and things will be better.  Just my two cents.
> >>>
> >>> Sam
> >>>
> >>>
> >>
> >> Sam, I think we are in agreement (at least with folks who responded to
> this thread).
> >> Or maybe I am not reading your mail right and you don't agree with Leo ?
> >>
> >> My own take and reason for calling for a change we are currently doing
> things is mostly due to the way we release.
> >>
> >> I would like to see a stable master (and I think we are in agreement
> with that).
> >> That means that development should not happen on master and that every
> commit that lands on master should be shippable.
> >>
> >> I personally have no issues with cherry-picking. So I would be fine
> cherry picking from a hot-fix branch into master, to fix a bug.
> >> The end result is that the next commit on master would still mean
> master is shippable/releasable.
> >>
> >> If we agree with this basic concept. The question becomes how do we get
> there, considering that master is now full of dev work and potential bug.
> >> The only releasable product we have are on the 4.3, 4.4 and previous
> release branches.
> >>
> >> Ideally, I would like to see master becomes 4.4. And work our way back,
> merging the new features that are already in master into the new master
> (based on 4.4).
> >> This could be quite complicated but we need to do it (or something like
> it).
> >>
> >> To move forward, we should make a proposal to the list and call for a
> vote.
> >>
> >> Any takers to start a wiki page proposing a new git process and how we
> could move to it (transition path) ?
> >>
> >>
> >> -Sebastien
> >>
> >>
> >>>
> >>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
> LSimons@schubergphilis.com>
> >>> wrote:
> >>>
> >>>> Hey folks,
> >>>>
> >>>> With 4.4.0 tagged, is now an opportune time to go and implement this?
> >>>>
> >>>> I would enthousiastically +1 and get crackin', but I’m not a
> committer so
> >>>> its not that practical for me to volunteer!
> >>>>
> >>>> I wanted to point out atlassian’s description of gitflow
> >>>>
> >>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
> >>>>
> >>>> which might be easier to read.
> >>>>
> >>>> Similarly, the git-flow scripts that help out with implementing this
> stuff
> >>>>
> >>>> https://github.com/nvie/gitflow
> >>>>
> >>>> they also describe the relationship between gitflow and dealing with
> >>>> multiple remotes
> >>>>
> >>>> https://www.atlassian.com/git/workflows#!pull-request
> >>>>
> >>>> Finally note atlassian’s free sourcetree GUI has built-in support for
> >>>> git-flow
> >>>>
> >>>> http://www.sourcetreeapp.com/
> >>>>
> >>>> Because cloudstack currently is full of rebasing and squashing and
> >>>> cherry-picking, you get very little benefit from a tree visualization
> tool
> >>>> (like this or gitk or ...) right now, but it would be *great* to have
> going
> >>>> forward.
> >>>>
> >>>>
> >>>> cheers,
> >>>>
> >>>>
> >>>> Leo
> >>>>
> >>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> >>>>
> >>>>> I would like to re-start this discussion.
> >>>>>
> >>>>> Rajani made some good points and someone mentioned Gitflow:
> >>>>>
> >>>>> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>
> >>>>> Thinking about our release procedure, we clearly need more tests and
> a
> >>>> CI. However it looks like this is going to take some time.
> >>>>>
> >>>>> In the meantime I think there is nothing preventing us from agreeing
> to
> >>>> 'git practices', we don't need tests or new infra, we just need to
> agree on
> >>>> the git workflow.
> >>>>>
> >>>>> Right now Master is really a development branch, we should make it a
> >>>> stable branch for production with very few commits.
> >>>>> This does not mean that we would release less, in contrary this would
> >>>> ensure that a commit to master means it's a production release.
> >>>>>
> >>>>> In addition gitflow [1] does not do cherry-picks (gets back to
> Rajani's
> >>>> point) everything is based on merges.
> >>>>>
> >>>>> I am of the opinion that git flow provides a nice process. It
> basically
> >>>> freezes master. Development happens in a 'develop' branch, releases
> >>>> branches are branched off of that and merged into master and back into
> >>>> develop….etc
> >>>>>
> >>>>> Please read [1] it's a good read.
> >>>>>
> >>>>> And let's discuss,
> >>>>>
> >>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>
> >>>>> -Sebastien
> >>>>>
> >>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
> Rajani.Karuturi@citrix.com>
> >>>> wrote:
> >>>>>
> >>>>>> There is also the problem of cherry-picking.
> >>>>>> As a contributor, I always endup creating multiple patches for each
> >>>> branch as they don’t cleanly apply on the upward branches. which means
> >>>> distinct commits for each branch and I don’t easily know which all
> branches
> >>>> my commit exists unless I do grep.
> >>>>>> if we follow merging strategy properly, apart from the first merge
> of
> >>>> the branch, everything else on top of it should be a painless merge.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ~Rajani
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
> >>>>>>
> >>>>>>> I think many of the bullet points are what we are currently doing
> >>>>>>> (guidelines for commit comments, feature branches need to stay in
> sync
> >>>> with
> >>>>>>> master, no back-merging). I also think that much of what we do now
> is
> >>>> done
> >>>>>>> the way it is simply because there *are* vast changes between
> versions.
> >>>>>>> Classes are getting shuffled around and changed all the time. If
> its
> >>>>>>> feasible to merge branch fixes to master, that's fine, but some
> quick
> >>>> tests
> >>>>>>> seem to indicate that this will be messy getting started.
> >>>>>>>
> >>>>>>> That leaves us with how we do releases. I'm fine with having single
> >>>>>>> branches for major releases(4.3) and tagging the commits where each
> >>>>>>> incremental release (4.3.x) is done. I'm trying to remember why we
> went
> >>>>>>> with the -forward, I'm sure it's in the mailing list somewhere, but
> >>>> one of
> >>>>>>> the nice things it provides is the ability for the release manager
> to
> >>>>>>> control what changes are made during code freeze while giving
> people a
> >>>>>>> place to stage fixes (though admittedly this is not always
> followed).
> >>>>>>> Without -forward, would the flow be for each dev to have their own
> >>>> repo and
> >>>>>>> issue pull requests for bugfixes?
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> >>>> Rajani.Karuturi@citrix.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Any other suggestions/objections/comments??
> >>>>>>>> Can we discuss this in detail and agree to a process??
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ~Rajani
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> >>>> Rajani.Karuturi@citrix.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
> >>>> merge(merge -s
> >>>>>>>> ours) for it and git will assume its merged but will not bring in
> any
> >>>>>>>> changes.
> >>>>>>>>>
> >>>>>>>>> If the branches diverged a lot, for example after a major
> rewrite, we
> >>>>>>>> could stop merging to that branch and above and make the fix
> manually.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ~Rajani
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>>>>>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> Yep, that's what I was referring to in that a particular fix
> for an
> >>>> old
> >>>>>>>>>> release may not apply to newer versions. That does happen.
> >>>>>>>>>>
> >>>>>>>>>> We used to mark those as "don't need to merge to branch x" in
> SVN
> >>>> and
> >>>>>>>> then
> >>>>>>>>>> you handed it however made sense on the applicable branch(es).
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>>>>>>> Stephen.Turner@citrix.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
> has to
> >>>> be
> >>>>>>>>>>> rewritten for newer versions because the code has changed?
> Don't
> >>>> the
> >>>>>>>>>>> branches diverge and you end up cherry-picking after that?
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Stephen Turner
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> >>>>>>>>>>> Sent: 30 May 2014 18:48
> >>>>>>>>>>> To: dev@cloudstack.apache.org
> >>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>>>>>>
> >>>>>>>>>>> I think this flow is something we should seriously consider.
> >>>>>>>>>>>
> >>>>>>>>>>> I find cherry picking from branch to branch to be error prone
> in
> >>>> that
> >>>>>>>> it's
> >>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
> >>>> branches
> >>>>>>>> and
> >>>>>>>>>>> you don't have any easy way to see the cherry picks are
> related.
> >>>>>>>>>>>
> >>>>>>>>>>> When I worked at HP, we had automated tools check to see if you
> >>>>>>>> checked a
> >>>>>>>>>>> fix into a prior release, but not later releases. In such a
> >>>> situation,
> >>>>>>>> you
> >>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
> was no
> >>>>>>>> longer
> >>>>>>>>>>> applicable in the later release(s), so you needed to mark it as
> >>>>>>>>>>> un-necessary (SVN supported this ability...not sure about Git).
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Our current git workflow is confusing with the *forward
> branches
> >>>> and
> >>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
> commit
> >>>> has
> >>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
> >>>> contributor, I
> >>>>>>>>>>>> endup creating patches for each branch as it doesn’t cleanly
> >>>> apply on
> >>>>>>>>>>>> different branches.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think we should have some guidelines. Here is what I
> propose.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
> >>>> 4.4.x,
> >>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
> accordingly
> >>>> on
> >>>>>>>>>>>> the respective branches.
> >>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
> branches
> >>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
> cherry-pick,
> >>>>>>>>>>>> we have two physically distinct commits for the same change or
> >>>> fix and
> >>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>>>>>>> 4.  There should always be a continous flow from release
> branches
> >>>> to
> >>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
> >>>> merged(either
> >>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable
> >>>> with
> >>>>>>>>>>>> git branch --contains
> >>>>>>>>>>>> *   Every bug fix should always flow from minimal release
> uptill
> >>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
> >>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> >>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>>>>>> *   If someone forgets to do the merge, the next time a new
> commit
> >>>>>>>>>>> is
> >>>>>>>>>>>> done this will also get merged.
> >>>>>>>>>>>> 5.  There should always be a continuous flow from master to
> >>>> feature
> >>>>>>>>>>>> branches. Meaning all feature branch owners should proactively
> >>>> take
> >>>>>>>>>>>> any new commits from master by doing a merge from master
> >>>>>>>>>>>> 6.  The commits from feature branch will make to master on
> code
> >>>>>>>>>>>> complete through a merge.
> >>>>>>>>>>>> 7.  There should never be a merge from master to release
> branches
> >>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
> >>>>>>>>>>>> should have atleast bug id and correct author information
> >>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
> >>>>>>>> <committer>
> >>>>>>>>>>>> for CASSANDRA-<ticket>
> >>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
> any bug
> >>>>>>>>>>>> in jira can be marked with fix version current release(4.4)
> only
> >>>> on
> >>>>>>>>>>>> RM's approval and only they can go to the release branch.
>  This
> >>>> can be
> >>>>>>>>>>>> done through jira and with certain rules.(may be using jira
> vote?)
> >>>>>>>>>>>> this would save the cherry-picking time and another branch
> >>>>>>>> maintenance.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ref:
> >>>>>>>>>>>>
> >>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>>>>>>
> >>>>>>>>>>>> ~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>*™*
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> *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
>
>


-- 


*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: [DISCUSS][PROPOSAL] git workflow

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

Mike,

Why not then just rename master to develop? people can still commit to
it. We don't need to have a branch named master and we can name any
branch so. in line with the gitflow article we could fork master of
off 4.4...

On Wed, Jul 23, 2014 at 6:13 PM, Mike Tutkowski
<mi...@solidfire.com> wrote:
> To start this all off, what about making a new branch call 'develop' off of
> 'master'? People can continue to commit to 'develop' as needed (as they
> were doing previously to 'master'), but only cherry pick well-tested
> features into 'master'.
>
> I know 'master' might not be currently in a shippable state (or maybe it
> is), but we can allow it to slowly make such a transition during the 4.5
> release and then keep it in a shippable going forward.
>
>
> On Wed, Jul 23, 2014 at 9:51 AM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
>
>>
>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
>> wrote:
>>
>> > Sebastien,
>> >
>> > It seems we can do what you are calling for is creating a branch
>> > called 'release'. We can merge back into that branch from 4.4, master,
>> > 4.3. I would like to see people that want a feature or bug fix in a
>> > branch make a fork of that branch and when that fork is working do a
>> > cherry-pick. The -forward concept is now used for that but it is
>> > broken because more then for one piece of work there are commits on
>> > it. This caused me conflicts during the release. Especially painfull
>> > as not all was intended to get into the release. We can create this
>> > 'release' branch now on the basis of 4.4 and start pulling in changes.
>>
>> Yes, that's what I am thinking about too, so +1
>>
>> Our master would become the -develop- in gitflow terms
>> The release branch you mention would become the -master- in gitflow terms
>>
>> If we start now, indeed we can create 'release' from 4.4 release tag
>> (voted and shipped).
>>
>> That means that to create 4.5 we will need to merge features back into
>> 'release'. it might be messy because some of those features are already in
>> our current master.
>>
>> But all of this will keep 'release' clean (we can keep track of bugs and
>> features that are in it in CHANGES file etc..)
>>
>>
>> > There is a question of control. Do we allow all committers to manage
>> > the release? I am for that but can imagine not everybody is.
>> >
>>
>> At first I would say that only the RM can commit to 'release'. As we get
>> the CI in place  we could relax this and allow commits that pass the CI to
>> get into 'release', but right now I would vote for a tighter control of
>> 'release'.
>>
>> > rule number 1 will be: you are going to do something to the code, you
>> > start by creating a branch.
>> >
>> > right?
>> >
>> > On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>> >>
>> >> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
>> wrote:
>> >>
>> >>> Hey everyone,
>> >>>
>> >>> I've been a developer for a handful of years and have had my share of
>> >>> experience with different version control systems.  I've used (for
>> better
>> >>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>> >>>
>> >>> Each of these solutions offers their own unique set of features,
>> strengths
>> >>> and weaknesses.  As there are so many systems that are good at specific
>> >>> things, it seems best to use the features that the chosen system is
>> best at.
>> >>>
>> >>> Git is great at branching, merging and using that structure to
>> maintain and
>> >>> control how changes get into the primary branches.  Git tools even make
>> >>> this easy by integrating directly into the "Gitflow" to make branching
>> and
>> >>> merging that much easier.  It would seem counter-intuitive to NOT make
>> use
>> >>> of these built-in capabilities.
>> >>>
>> >>> In addition to that, I know that the current method of change
>> management is
>> >>> incredibly frustrating to work with, and works directly against the
>> way a
>> >>> typical Git user would expect it to be structured.  I should NEVER have
>> >>> problem compiling and running something on master.  I should not have
>> >>> problems building anything on a release branch.  A feature/bugfix
>> branch is
>> >>> where things can be, and often are, broken or unstable.  There have
>> been
>> >>> many times working in Cloudstack where I've had to search for a stable
>> >>> revision on master, and that's just plain wrong.
>> >>>
>> >>> I do realize that having this many developers working on so many
>> features
>> >>> and bugfixes will result in a large number of branches.  I don't
>> believe
>> >>> this is a good argument against using a branching method, though - I
>> >>> believe that the current system is even more confusing and difficult
>> to use.
>> >>>
>> >>> I could pontificate on change management quite a bit more, but my
>> opinion
>> >>> in summary would basically be:  use Git the way it was meant to be
>> used,
>> >>> and things will be better.  Just my two cents.
>> >>>
>> >>> Sam
>> >>>
>> >>>
>> >>
>> >> Sam, I think we are in agreement (at least with folks who responded to
>> this thread).
>> >> Or maybe I am not reading your mail right and you don't agree with Leo ?
>> >>
>> >> My own take and reason for calling for a change we are currently doing
>> things is mostly due to the way we release.
>> >>
>> >> I would like to see a stable master (and I think we are in agreement
>> with that).
>> >> That means that development should not happen on master and that every
>> commit that lands on master should be shippable.
>> >>
>> >> I personally have no issues with cherry-picking. So I would be fine
>> cherry picking from a hot-fix branch into master, to fix a bug.
>> >> The end result is that the next commit on master would still mean
>> master is shippable/releasable.
>> >>
>> >> If we agree with this basic concept. The question becomes how do we get
>> there, considering that master is now full of dev work and potential bug.
>> >> The only releasable product we have are on the 4.3, 4.4 and previous
>> release branches.
>> >>
>> >> Ideally, I would like to see master becomes 4.4. And work our way back,
>> merging the new features that are already in master into the new master
>> (based on 4.4).
>> >> This could be quite complicated but we need to do it (or something like
>> it).
>> >>
>> >> To move forward, we should make a proposal to the list and call for a
>> vote.
>> >>
>> >> Any takers to start a wiki page proposing a new git process and how we
>> could move to it (transition path) ?
>> >>
>> >>
>> >> -Sebastien
>> >>
>> >>
>> >>>
>> >>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
>> LSimons@schubergphilis.com>
>> >>> wrote:
>> >>>
>> >>>> Hey folks,
>> >>>>
>> >>>> With 4.4.0 tagged, is now an opportune time to go and implement this?
>> >>>>
>> >>>> I would enthousiastically +1 and get crackin', but I’m not a
>> committer so
>> >>>> its not that practical for me to volunteer!
>> >>>>
>> >>>> I wanted to point out atlassian’s description of gitflow
>> >>>>
>> >>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>> >>>>
>> >>>> which might be easier to read.
>> >>>>
>> >>>> Similarly, the git-flow scripts that help out with implementing this
>> stuff
>> >>>>
>> >>>> https://github.com/nvie/gitflow
>> >>>>
>> >>>> they also describe the relationship between gitflow and dealing with
>> >>>> multiple remotes
>> >>>>
>> >>>> https://www.atlassian.com/git/workflows#!pull-request
>> >>>>
>> >>>> Finally note atlassian’s free sourcetree GUI has built-in support for
>> >>>> git-flow
>> >>>>
>> >>>> http://www.sourcetreeapp.com/
>> >>>>
>> >>>> Because cloudstack currently is full of rebasing and squashing and
>> >>>> cherry-picking, you get very little benefit from a tree visualization
>> tool
>> >>>> (like this or gitk or ...) right now, but it would be *great* to have
>> going
>> >>>> forward.
>> >>>>
>> >>>>
>> >>>> cheers,
>> >>>>
>> >>>>
>> >>>> Leo
>> >>>>
>> >>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>> >>>>
>> >>>>> I would like to re-start this discussion.
>> >>>>>
>> >>>>> Rajani made some good points and someone mentioned Gitflow:
>> >>>>>
>> >>>>> http://nvie.com/posts/a-successful-git-branching-model/
>> >>>>>
>> >>>>> Thinking about our release procedure, we clearly need more tests and
>> a
>> >>>> CI. However it looks like this is going to take some time.
>> >>>>>
>> >>>>> In the meantime I think there is nothing preventing us from agreeing
>> to
>> >>>> 'git practices', we don't need tests or new infra, we just need to
>> agree on
>> >>>> the git workflow.
>> >>>>>
>> >>>>> Right now Master is really a development branch, we should make it a
>> >>>> stable branch for production with very few commits.
>> >>>>> This does not mean that we would release less, in contrary this would
>> >>>> ensure that a commit to master means it's a production release.
>> >>>>>
>> >>>>> In addition gitflow [1] does not do cherry-picks (gets back to
>> Rajani's
>> >>>> point) everything is based on merges.
>> >>>>>
>> >>>>> I am of the opinion that git flow provides a nice process. It
>> basically
>> >>>> freezes master. Development happens in a 'develop' branch, releases
>> >>>> branches are branched off of that and merged into master and back into
>> >>>> develop….etc
>> >>>>>
>> >>>>> Please read [1] it's a good read.
>> >>>>>
>> >>>>> And let's discuss,
>> >>>>>
>> >>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>> >>>>>
>> >>>>> -Sebastien
>> >>>>>
>> >>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
>> Rajani.Karuturi@citrix.com>
>> >>>> wrote:
>> >>>>>
>> >>>>>> There is also the problem of cherry-picking.
>> >>>>>> As a contributor, I always endup creating multiple patches for each
>> >>>> branch as they don’t cleanly apply on the upward branches. which means
>> >>>> distinct commits for each branch and I don’t easily know which all
>> branches
>> >>>> my commit exists unless I do grep.
>> >>>>>> if we follow merging strategy properly, apart from the first merge
>> of
>> >>>> the branch, everything else on top of it should be a painless merge.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> ~Rajani
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
>> >>>>>>
>> >>>>>>> I think many of the bullet points are what we are currently doing
>> >>>>>>> (guidelines for commit comments, feature branches need to stay in
>> sync
>> >>>> with
>> >>>>>>> master, no back-merging). I also think that much of what we do now
>> is
>> >>>> done
>> >>>>>>> the way it is simply because there *are* vast changes between
>> versions.
>> >>>>>>> Classes are getting shuffled around and changed all the time. If
>> its
>> >>>>>>> feasible to merge branch fixes to master, that's fine, but some
>> quick
>> >>>> tests
>> >>>>>>> seem to indicate that this will be messy getting started.
>> >>>>>>>
>> >>>>>>> That leaves us with how we do releases. I'm fine with having single
>> >>>>>>> branches for major releases(4.3) and tagging the commits where each
>> >>>>>>> incremental release (4.3.x) is done. I'm trying to remember why we
>> went
>> >>>>>>> with the -forward, I'm sure it's in the mailing list somewhere, but
>> >>>> one of
>> >>>>>>> the nice things it provides is the ability for the release manager
>> to
>> >>>>>>> control what changes are made during code freeze while giving
>> people a
>> >>>>>>> place to stage fixes (though admittedly this is not always
>> followed).
>> >>>>>>> Without -forward, would the flow be for each dev to have their own
>> >>>> repo and
>> >>>>>>> issue pull requests for bugfixes?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>> >>>> Rajani.Karuturi@citrix.com>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> Any other suggestions/objections/comments??
>> >>>>>>>> Can we discuss this in detail and agree to a process??
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> ~Rajani
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>> >>>> Rajani.Karuturi@citrix.com>
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>> >>>> merge(merge -s
>> >>>>>>>> ours) for it and git will assume its merged but will not bring in
>> any
>> >>>>>>>> changes.
>> >>>>>>>>>
>> >>>>>>>>> If the branches diverged a lot, for example after a major
>> rewrite, we
>> >>>>>>>> could stop merging to that branch and above and make the fix
>> manually.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> ~Rajani
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>> >>>>>>>> mike.tutkowski@solidfire.com> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Yep, that's what I was referring to in that a particular fix
>> for an
>> >>>> old
>> >>>>>>>>>> release may not apply to newer versions. That does happen.
>> >>>>>>>>>>
>> >>>>>>>>>> We used to mark those as "don't need to merge to branch x" in
>> SVN
>> >>>> and
>> >>>>>>>> then
>> >>>>>>>>>> you handed it however made sense on the applicable branch(es).
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>> >>>>>>>> Stephen.Turner@citrix.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
>> has to
>> >>>> be
>> >>>>>>>>>>> rewritten for newer versions because the code has changed?
>> Don't
>> >>>> the
>> >>>>>>>>>>> branches diverge and you end up cherry-picking after that?
>> >>>>>>>>>>>
>> >>>>>>>>>>> --
>> >>>>>>>>>>> Stephen Turner
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> -----Original Message-----
>> >>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>> >>>>>>>>>>> Sent: 30 May 2014 18:48
>> >>>>>>>>>>> To: dev@cloudstack.apache.org
>> >>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>> >>>>>>>>>>>
>> >>>>>>>>>>> I think this flow is something we should seriously consider.
>> >>>>>>>>>>>
>> >>>>>>>>>>> I find cherry picking from branch to branch to be error prone
>> in
>> >>>> that
>> >>>>>>>> it's
>> >>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
>> >>>> branches
>> >>>>>>>> and
>> >>>>>>>>>>> you don't have any easy way to see the cherry picks are
>> related.
>> >>>>>>>>>>>
>> >>>>>>>>>>> When I worked at HP, we had automated tools check to see if you
>> >>>>>>>> checked a
>> >>>>>>>>>>> fix into a prior release, but not later releases. In such a
>> >>>> situation,
>> >>>>>>>> you
>> >>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
>> was no
>> >>>>>>>> longer
>> >>>>>>>>>>> applicable in the later release(s), so you needed to mark it as
>> >>>>>>>>>>> un-necessary (SVN supported this ability...not sure about Git).
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>> >>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Hi all,
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Our current git workflow is confusing with the *forward
>> branches
>> >>>> and
>> >>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
>> commit
>> >>>> has
>> >>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>> >>>> contributor, I
>> >>>>>>>>>>>> endup creating patches for each branch as it doesn’t cleanly
>> >>>> apply on
>> >>>>>>>>>>>> different branches.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I think we should have some guidelines. Here is what I
>> propose.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
>> >>>> 4.4.x,
>> >>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
>> accordingly
>> >>>> on
>> >>>>>>>>>>>> the respective branches.
>> >>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
>> branches
>> >>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>> >>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
>> cherry-pick,
>> >>>>>>>>>>>> we have two physically distinct commits for the same change or
>> >>>> fix and
>> >>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>> >>>>>>>>>>>> 4.  There should always be a continous flow from release
>> branches
>> >>>> to
>> >>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
>> >>>> merged(either
>> >>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable
>> >>>> with
>> >>>>>>>>>>>> git branch --contains
>> >>>>>>>>>>>> *   Every bug fix should always flow from minimal release
>> uptill
>> >>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>> >>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>> >>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>> >>>>>>>>>>>> *   If someone forgets to do the merge, the next time a new
>> commit
>> >>>>>>>>>>> is
>> >>>>>>>>>>>> done this will also get merged.
>> >>>>>>>>>>>> 5.  There should always be a continuous flow from master to
>> >>>> feature
>> >>>>>>>>>>>> branches. Meaning all feature branch owners should proactively
>> >>>> take
>> >>>>>>>>>>>> any new commits from master by doing a merge from master
>> >>>>>>>>>>>> 6.  The commits from feature branch will make to master on
>> code
>> >>>>>>>>>>>> complete through a merge.
>> >>>>>>>>>>>> 7.  There should never be a merge from master to release
>> branches
>> >>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>> >>>>>>>>>>>> should have atleast bug id and correct author information
>> >>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>> >>>>>>>> <committer>
>> >>>>>>>>>>>> for CASSANDRA-<ticket>
>> >>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
>> any bug
>> >>>>>>>>>>>> in jira can be marked with fix version current release(4.4)
>> only
>> >>>> on
>> >>>>>>>>>>>> RM's approval and only they can go to the release branch.
>>  This
>> >>>> can be
>> >>>>>>>>>>>> done through jira and with certain rules.(may be using jira
>> vote?)
>> >>>>>>>>>>>> this would save the cherry-picking time and another branch
>> >>>>>>>> maintenance.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Ref:
>> >>>>>>>>>>>>
>> >>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>> >>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> ~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>*™*
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> --
>> >>>>>>>>>> *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
>>
>>
>
>
> --
> *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: [DISCUSS][PROPOSAL] git workflow

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

To start this all off, what about making a new branch call 'develop' off of
'master'? People can continue to commit to 'develop' as needed (as they
were doing previously to 'master'), but only cherry pick well-tested
features into 'master'.

I know 'master' might not be currently in a shippable state (or maybe it
is), but we can allow it to slowly make such a transition during the 4.5
release and then keep it in a shippable going forward.


On Wed, Jul 23, 2014 at 9:51 AM, Sebastien Goasguen <ru...@gmail.com>
wrote:

>
> On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com>
> wrote:
>
> > Sebastien,
> >
> > It seems we can do what you are calling for is creating a branch
> > called 'release'. We can merge back into that branch from 4.4, master,
> > 4.3. I would like to see people that want a feature or bug fix in a
> > branch make a fork of that branch and when that fork is working do a
> > cherry-pick. The -forward concept is now used for that but it is
> > broken because more then for one piece of work there are commits on
> > it. This caused me conflicts during the release. Especially painfull
> > as not all was intended to get into the release. We can create this
> > 'release' branch now on the basis of 4.4 and start pulling in changes.
>
> Yes, that's what I am thinking about too, so +1
>
> Our master would become the -develop- in gitflow terms
> The release branch you mention would become the -master- in gitflow terms
>
> If we start now, indeed we can create 'release' from 4.4 release tag
> (voted and shipped).
>
> That means that to create 4.5 we will need to merge features back into
> 'release'. it might be messy because some of those features are already in
> our current master.
>
> But all of this will keep 'release' clean (we can keep track of bugs and
> features that are in it in CHANGES file etc..)
>
>
> > There is a question of control. Do we allow all committers to manage
> > the release? I am for that but can imagine not everybody is.
> >
>
> At first I would say that only the RM can commit to 'release'. As we get
> the CI in place  we could relax this and allow commits that pass the CI to
> get into 'release', but right now I would vote for a tighter control of
> 'release'.
>
> > rule number 1 will be: you are going to do something to the code, you
> > start by creating a branch.
> >
> > right?
> >
> > On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> >>
> >> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com>
> wrote:
> >>
> >>> Hey everyone,
> >>>
> >>> I've been a developer for a handful of years and have had my share of
> >>> experience with different version control systems.  I've used (for
> better
> >>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>
> >>> Each of these solutions offers their own unique set of features,
> strengths
> >>> and weaknesses.  As there are so many systems that are good at specific
> >>> things, it seems best to use the features that the chosen system is
> best at.
> >>>
> >>> Git is great at branching, merging and using that structure to
> maintain and
> >>> control how changes get into the primary branches.  Git tools even make
> >>> this easy by integrating directly into the "Gitflow" to make branching
> and
> >>> merging that much easier.  It would seem counter-intuitive to NOT make
> use
> >>> of these built-in capabilities.
> >>>
> >>> In addition to that, I know that the current method of change
> management is
> >>> incredibly frustrating to work with, and works directly against the
> way a
> >>> typical Git user would expect it to be structured.  I should NEVER have
> >>> problem compiling and running something on master.  I should not have
> >>> problems building anything on a release branch.  A feature/bugfix
> branch is
> >>> where things can be, and often are, broken or unstable.  There have
> been
> >>> many times working in Cloudstack where I've had to search for a stable
> >>> revision on master, and that's just plain wrong.
> >>>
> >>> I do realize that having this many developers working on so many
> features
> >>> and bugfixes will result in a large number of branches.  I don't
> believe
> >>> this is a good argument against using a branching method, though - I
> >>> believe that the current system is even more confusing and difficult
> to use.
> >>>
> >>> I could pontificate on change management quite a bit more, but my
> opinion
> >>> in summary would basically be:  use Git the way it was meant to be
> used,
> >>> and things will be better.  Just my two cents.
> >>>
> >>> Sam
> >>>
> >>>
> >>
> >> Sam, I think we are in agreement (at least with folks who responded to
> this thread).
> >> Or maybe I am not reading your mail right and you don't agree with Leo ?
> >>
> >> My own take and reason for calling for a change we are currently doing
> things is mostly due to the way we release.
> >>
> >> I would like to see a stable master (and I think we are in agreement
> with that).
> >> That means that development should not happen on master and that every
> commit that lands on master should be shippable.
> >>
> >> I personally have no issues with cherry-picking. So I would be fine
> cherry picking from a hot-fix branch into master, to fix a bug.
> >> The end result is that the next commit on master would still mean
> master is shippable/releasable.
> >>
> >> If we agree with this basic concept. The question becomes how do we get
> there, considering that master is now full of dev work and potential bug.
> >> The only releasable product we have are on the 4.3, 4.4 and previous
> release branches.
> >>
> >> Ideally, I would like to see master becomes 4.4. And work our way back,
> merging the new features that are already in master into the new master
> (based on 4.4).
> >> This could be quite complicated but we need to do it (or something like
> it).
> >>
> >> To move forward, we should make a proposal to the list and call for a
> vote.
> >>
> >> Any takers to start a wiki page proposing a new git process and how we
> could move to it (transition path) ?
> >>
> >>
> >> -Sebastien
> >>
> >>
> >>>
> >>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
> LSimons@schubergphilis.com>
> >>> wrote:
> >>>
> >>>> Hey folks,
> >>>>
> >>>> With 4.4.0 tagged, is now an opportune time to go and implement this?
> >>>>
> >>>> I would enthousiastically +1 and get crackin', but I’m not a
> committer so
> >>>> its not that practical for me to volunteer!
> >>>>
> >>>> I wanted to point out atlassian’s description of gitflow
> >>>>
> >>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
> >>>>
> >>>> which might be easier to read.
> >>>>
> >>>> Similarly, the git-flow scripts that help out with implementing this
> stuff
> >>>>
> >>>> https://github.com/nvie/gitflow
> >>>>
> >>>> they also describe the relationship between gitflow and dealing with
> >>>> multiple remotes
> >>>>
> >>>> https://www.atlassian.com/git/workflows#!pull-request
> >>>>
> >>>> Finally note atlassian’s free sourcetree GUI has built-in support for
> >>>> git-flow
> >>>>
> >>>> http://www.sourcetreeapp.com/
> >>>>
> >>>> Because cloudstack currently is full of rebasing and squashing and
> >>>> cherry-picking, you get very little benefit from a tree visualization
> tool
> >>>> (like this or gitk or ...) right now, but it would be *great* to have
> going
> >>>> forward.
> >>>>
> >>>>
> >>>> cheers,
> >>>>
> >>>>
> >>>> Leo
> >>>>
> >>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> >>>>
> >>>>> I would like to re-start this discussion.
> >>>>>
> >>>>> Rajani made some good points and someone mentioned Gitflow:
> >>>>>
> >>>>> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>
> >>>>> Thinking about our release procedure, we clearly need more tests and
> a
> >>>> CI. However it looks like this is going to take some time.
> >>>>>
> >>>>> In the meantime I think there is nothing preventing us from agreeing
> to
> >>>> 'git practices', we don't need tests or new infra, we just need to
> agree on
> >>>> the git workflow.
> >>>>>
> >>>>> Right now Master is really a development branch, we should make it a
> >>>> stable branch for production with very few commits.
> >>>>> This does not mean that we would release less, in contrary this would
> >>>> ensure that a commit to master means it's a production release.
> >>>>>
> >>>>> In addition gitflow [1] does not do cherry-picks (gets back to
> Rajani's
> >>>> point) everything is based on merges.
> >>>>>
> >>>>> I am of the opinion that git flow provides a nice process. It
> basically
> >>>> freezes master. Development happens in a 'develop' branch, releases
> >>>> branches are branched off of that and merged into master and back into
> >>>> develop….etc
> >>>>>
> >>>>> Please read [1] it's a good read.
> >>>>>
> >>>>> And let's discuss,
> >>>>>
> >>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>
> >>>>> -Sebastien
> >>>>>
> >>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
> Rajani.Karuturi@citrix.com>
> >>>> wrote:
> >>>>>
> >>>>>> There is also the problem of cherry-picking.
> >>>>>> As a contributor, I always endup creating multiple patches for each
> >>>> branch as they don’t cleanly apply on the upward branches. which means
> >>>> distinct commits for each branch and I don’t easily know which all
> branches
> >>>> my commit exists unless I do grep.
> >>>>>> if we follow merging strategy properly, apart from the first merge
> of
> >>>> the branch, everything else on top of it should be a painless merge.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ~Rajani
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
> >>>>>>
> >>>>>>> I think many of the bullet points are what we are currently doing
> >>>>>>> (guidelines for commit comments, feature branches need to stay in
> sync
> >>>> with
> >>>>>>> master, no back-merging). I also think that much of what we do now
> is
> >>>> done
> >>>>>>> the way it is simply because there *are* vast changes between
> versions.
> >>>>>>> Classes are getting shuffled around and changed all the time. If
> its
> >>>>>>> feasible to merge branch fixes to master, that's fine, but some
> quick
> >>>> tests
> >>>>>>> seem to indicate that this will be messy getting started.
> >>>>>>>
> >>>>>>> That leaves us with how we do releases. I'm fine with having single
> >>>>>>> branches for major releases(4.3) and tagging the commits where each
> >>>>>>> incremental release (4.3.x) is done. I'm trying to remember why we
> went
> >>>>>>> with the -forward, I'm sure it's in the mailing list somewhere, but
> >>>> one of
> >>>>>>> the nice things it provides is the ability for the release manager
> to
> >>>>>>> control what changes are made during code freeze while giving
> people a
> >>>>>>> place to stage fixes (though admittedly this is not always
> followed).
> >>>>>>> Without -forward, would the flow be for each dev to have their own
> >>>> repo and
> >>>>>>> issue pull requests for bugfixes?
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> >>>> Rajani.Karuturi@citrix.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Any other suggestions/objections/comments??
> >>>>>>>> Can we discuss this in detail and agree to a process??
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ~Rajani
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> >>>> Rajani.Karuturi@citrix.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
> >>>> merge(merge -s
> >>>>>>>> ours) for it and git will assume its merged but will not bring in
> any
> >>>>>>>> changes.
> >>>>>>>>>
> >>>>>>>>> If the branches diverged a lot, for example after a major
> rewrite, we
> >>>>>>>> could stop merging to that branch and above and make the fix
> manually.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ~Rajani
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>>>>>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> Yep, that's what I was referring to in that a particular fix
> for an
> >>>> old
> >>>>>>>>>> release may not apply to newer versions. That does happen.
> >>>>>>>>>>
> >>>>>>>>>> We used to mark those as "don't need to merge to branch x" in
> SVN
> >>>> and
> >>>>>>>> then
> >>>>>>>>>> you handed it however made sense on the applicable branch(es).
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>>>>>>> Stephen.Turner@citrix.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or
> has to
> >>>> be
> >>>>>>>>>>> rewritten for newer versions because the code has changed?
> Don't
> >>>> the
> >>>>>>>>>>> branches diverge and you end up cherry-picking after that?
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Stephen Turner
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> >>>>>>>>>>> Sent: 30 May 2014 18:48
> >>>>>>>>>>> To: dev@cloudstack.apache.org
> >>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>>>>>>
> >>>>>>>>>>> I think this flow is something we should seriously consider.
> >>>>>>>>>>>
> >>>>>>>>>>> I find cherry picking from branch to branch to be error prone
> in
> >>>> that
> >>>>>>>> it's
> >>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
> >>>> branches
> >>>>>>>> and
> >>>>>>>>>>> you don't have any easy way to see the cherry picks are
> related.
> >>>>>>>>>>>
> >>>>>>>>>>> When I worked at HP, we had automated tools check to see if you
> >>>>>>>> checked a
> >>>>>>>>>>> fix into a prior release, but not later releases. In such a
> >>>> situation,
> >>>>>>>> you
> >>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in
> was no
> >>>>>>>> longer
> >>>>>>>>>>> applicable in the later release(s), so you needed to mark it as
> >>>>>>>>>>> un-necessary (SVN supported this ability...not sure about Git).
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Our current git workflow is confusing with the *forward
> branches
> >>>> and
> >>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the
> commit
> >>>> has
> >>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
> >>>> contributor, I
> >>>>>>>>>>>> endup creating patches for each branch as it doesn’t cleanly
> >>>> apply on
> >>>>>>>>>>>> different branches.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think we should have some guidelines. Here is what I
> propose.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
> >>>> 4.4.x,
> >>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
> accordingly
> >>>> on
> >>>>>>>>>>>> the respective branches.
> >>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many
> branches
> >>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
> cherry-pick,
> >>>>>>>>>>>> we have two physically distinct commits for the same change or
> >>>> fix and
> >>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>>>>>>> 4.  There should always be a continous flow from release
> branches
> >>>> to
> >>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
> >>>> merged(either
> >>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable
> >>>> with
> >>>>>>>>>>>> git branch --contains
> >>>>>>>>>>>> *   Every bug fix should always flow from minimal release
> uptill
> >>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
> >>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> >>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>>>>>> *   If someone forgets to do the merge, the next time a new
> commit
> >>>>>>>>>>> is
> >>>>>>>>>>>> done this will also get merged.
> >>>>>>>>>>>> 5.  There should always be a continuous flow from master to
> >>>> feature
> >>>>>>>>>>>> branches. Meaning all feature branch owners should proactively
> >>>> take
> >>>>>>>>>>>> any new commits from master by doing a merge from master
> >>>>>>>>>>>> 6.  The commits from feature branch will make to master on
> code
> >>>>>>>>>>>> complete through a merge.
> >>>>>>>>>>>> 7.  There should never be a merge from master to release
> branches
> >>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
> >>>>>>>>>>>> should have atleast bug id and correct author information
> >>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
> >>>>>>>> <committer>
> >>>>>>>>>>>> for CASSANDRA-<ticket>
> >>>>>>>>>>>> 9.  Once the release branch is created(after code freeze),
> any bug
> >>>>>>>>>>>> in jira can be marked with fix version current release(4.4)
> only
> >>>> on
> >>>>>>>>>>>> RM's approval and only they can go to the release branch.
>  This
> >>>> can be
> >>>>>>>>>>>> done through jira and with certain rules.(may be using jira
> vote?)
> >>>>>>>>>>>> this would save the cherry-picking time and another branch
> >>>>>>>> maintenance.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ref:
> >>>>>>>>>>>>
> >>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>>>>>>
> >>>>>>>>>>>> ~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>*™*
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> *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
>
>


-- 
*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: [DISCUSS][PROPOSAL] git workflow

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

On Jul 23, 2014, at 11:38 AM, daan Hoogland <da...@gmail.com> wrote:

> Sebastien,
> 
> It seems we can do what you are calling for is creating a branch
> called 'release'. We can merge back into that branch from 4.4, master,
> 4.3. I would like to see people that want a feature or bug fix in a
> branch make a fork of that branch and when that fork is working do a
> cherry-pick. The -forward concept is now used for that but it is
> broken because more then for one piece of work there are commits on
> it. This caused me conflicts during the release. Especially painfull
> as not all was intended to get into the release. We can create this
> 'release' branch now on the basis of 4.4 and start pulling in changes.

Yes, that's what I am thinking about too, so +1

Our master would become the -develop- in gitflow terms
The release branch you mention would become the -master- in gitflow terms

If we start now, indeed we can create 'release' from 4.4 release tag (voted and shipped).

That means that to create 4.5 we will need to merge features back into 'release'. it might be messy because some of those features are already in our current master.

But all of this will keep 'release' clean (we can keep track of bugs and features that are in it in CHANGES file etc..) 


> There is a question of control. Do we allow all committers to manage
> the release? I am for that but can imagine not everybody is.
> 

At first I would say that only the RM can commit to 'release'. As we get the CI in place  we could relax this and allow commits that pass the CI to get into 'release', but right now I would vote for a tighter control of 'release'.

> rule number 1 will be: you are going to do something to the code, you
> start by creating a branch.
> 
> right?
> 
> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <ru...@gmail.com> wrote:
>> 
>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com> wrote:
>> 
>>> Hey everyone,
>>> 
>>> I've been a developer for a handful of years and have had my share of
>>> experience with different version control systems.  I've used (for better
>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>> 
>>> Each of these solutions offers their own unique set of features, strengths
>>> and weaknesses.  As there are so many systems that are good at specific
>>> things, it seems best to use the features that the chosen system is best at.
>>> 
>>> Git is great at branching, merging and using that structure to maintain and
>>> control how changes get into the primary branches.  Git tools even make
>>> this easy by integrating directly into the "Gitflow" to make branching and
>>> merging that much easier.  It would seem counter-intuitive to NOT make use
>>> of these built-in capabilities.
>>> 
>>> In addition to that, I know that the current method of change management is
>>> incredibly frustrating to work with, and works directly against the way a
>>> typical Git user would expect it to be structured.  I should NEVER have
>>> problem compiling and running something on master.  I should not have
>>> problems building anything on a release branch.  A feature/bugfix branch is
>>> where things can be, and often are, broken or unstable.  There have been
>>> many times working in Cloudstack where I've had to search for a stable
>>> revision on master, and that's just plain wrong.
>>> 
>>> I do realize that having this many developers working on so many features
>>> and bugfixes will result in a large number of branches.  I don't believe
>>> this is a good argument against using a branching method, though - I
>>> believe that the current system is even more confusing and difficult to use.
>>> 
>>> I could pontificate on change management quite a bit more, but my opinion
>>> in summary would basically be:  use Git the way it was meant to be used,
>>> and things will be better.  Just my two cents.
>>> 
>>> Sam
>>> 
>>> 
>> 
>> Sam, I think we are in agreement (at least with folks who responded to this thread).
>> Or maybe I am not reading your mail right and you don't agree with Leo ?
>> 
>> My own take and reason for calling for a change we are currently doing things is mostly due to the way we release.
>> 
>> I would like to see a stable master (and I think we are in agreement with that).
>> That means that development should not happen on master and that every commit that lands on master should be shippable.
>> 
>> I personally have no issues with cherry-picking. So I would be fine cherry picking from a hot-fix branch into master, to fix a bug.
>> The end result is that the next commit on master would still mean master is shippable/releasable.
>> 
>> If we agree with this basic concept. The question becomes how do we get there, considering that master is now full of dev work and potential bug.
>> The only releasable product we have are on the 4.3, 4.4 and previous release branches.
>> 
>> Ideally, I would like to see master becomes 4.4. And work our way back, merging the new features that are already in master into the new master (based on 4.4).
>> This could be quite complicated but we need to do it (or something like it).
>> 
>> To move forward, we should make a proposal to the list and call for a vote.
>> 
>> Any takers to start a wiki page proposing a new git process and how we could move to it (transition path) ?
>> 
>> 
>> -Sebastien
>> 
>> 
>>> 
>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <LS...@schubergphilis.com>
>>> wrote:
>>> 
>>>> Hey folks,
>>>> 
>>>> With 4.4.0 tagged, is now an opportune time to go and implement this?
>>>> 
>>>> I would enthousiastically +1 and get crackin', but I’m not a committer so
>>>> its not that practical for me to volunteer!
>>>> 
>>>> I wanted to point out atlassian’s description of gitflow
>>>> 
>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>> 
>>>> which might be easier to read.
>>>> 
>>>> Similarly, the git-flow scripts that help out with implementing this stuff
>>>> 
>>>> https://github.com/nvie/gitflow
>>>> 
>>>> they also describe the relationship between gitflow and dealing with
>>>> multiple remotes
>>>> 
>>>> https://www.atlassian.com/git/workflows#!pull-request
>>>> 
>>>> Finally note atlassian’s free sourcetree GUI has built-in support for
>>>> git-flow
>>>> 
>>>> http://www.sourcetreeapp.com/
>>>> 
>>>> Because cloudstack currently is full of rebasing and squashing and
>>>> cherry-picking, you get very little benefit from a tree visualization tool
>>>> (like this or gitk or ...) right now, but it would be *great* to have going
>>>> forward.
>>>> 
>>>> 
>>>> cheers,
>>>> 
>>>> 
>>>> Leo
>>>> 
>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>>>> 
>>>>> I would like to re-start this discussion.
>>>>> 
>>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>> 
>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>> 
>>>>> Thinking about our release procedure, we clearly need more tests and a
>>>> CI. However it looks like this is going to take some time.
>>>>> 
>>>>> In the meantime I think there is nothing preventing us from agreeing to
>>>> 'git practices', we don't need tests or new infra, we just need to agree on
>>>> the git workflow.
>>>>> 
>>>>> Right now Master is really a development branch, we should make it a
>>>> stable branch for production with very few commits.
>>>>> This does not mean that we would release less, in contrary this would
>>>> ensure that a commit to master means it's a production release.
>>>>> 
>>>>> In addition gitflow [1] does not do cherry-picks (gets back to Rajani's
>>>> point) everything is based on merges.
>>>>> 
>>>>> I am of the opinion that git flow provides a nice process. It basically
>>>> freezes master. Development happens in a 'develop' branch, releases
>>>> branches are branched off of that and merged into master and back into
>>>> develop….etc
>>>>> 
>>>>> Please read [1] it's a good read.
>>>>> 
>>>>> And let's discuss,
>>>>> 
>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>>>> 
>>>>> -Sebastien
>>>>> 
>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Ra...@citrix.com>
>>>> wrote:
>>>>> 
>>>>>> There is also the problem of cherry-picking.
>>>>>> As a contributor, I always endup creating multiple patches for each
>>>> branch as they don’t cleanly apply on the upward branches. which means
>>>> distinct commits for each branch and I don’t easily know which all branches
>>>> my commit exists unless I do grep.
>>>>>> if we follow merging strategy properly, apart from the first merge of
>>>> the branch, everything else on top of it should be a painless merge.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ~Rajani
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
>>>>>> 
>>>>>>> I think many of the bullet points are what we are currently doing
>>>>>>> (guidelines for commit comments, feature branches need to stay in sync
>>>> with
>>>>>>> master, no back-merging). I also think that much of what we do now is
>>>> done
>>>>>>> the way it is simply because there *are* vast changes between versions.
>>>>>>> Classes are getting shuffled around and changed all the time. If its
>>>>>>> feasible to merge branch fixes to master, that's fine, but some quick
>>>> tests
>>>>>>> seem to indicate that this will be messy getting started.
>>>>>>> 
>>>>>>> That leaves us with how we do releases. I'm fine with having single
>>>>>>> branches for major releases(4.3) and tagging the commits where each
>>>>>>> incremental release (4.3.x) is done. I'm trying to remember why we went
>>>>>>> with the -forward, I'm sure it's in the mailing list somewhere, but
>>>> one of
>>>>>>> the nice things it provides is the ability for the release manager to
>>>>>>> control what changes are made during code freeze while giving people a
>>>>>>> place to stage fixes (though admittedly this is not always followed).
>>>>>>> Without -forward, would the flow be for each dev to have their own
>>>> repo and
>>>>>>> issue pull requests for bugfixes?
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>>> Rajani.Karuturi@citrix.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Any other suggestions/objections/comments??
>>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ~Rajani
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>>> Rajani.Karuturi@citrix.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>>>> merge(merge -s
>>>>>>>> ours) for it and git will assume its merged but will not bring in any
>>>>>>>> changes.
>>>>>>>>> 
>>>>>>>>> If the branches diverged a lot, for example after a major rewrite, we
>>>>>>>> could stop merging to that branch and above and make the fix manually.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ~Rajani
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> 
>>>>>>>>>> Yep, that's what I was referring to in that a particular fix for an
>>>> old
>>>>>>>>>> release may not apply to newer versions. That does happen.
>>>>>>>>>> 
>>>>>>>>>> We used to mark those as "don't need to merge to branch x" in SVN
>>>> and
>>>>>>>> then
>>>>>>>>>> you handed it however made sense on the applicable branch(es).
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or has to
>>>> be
>>>>>>>>>>> rewritten for newer versions because the code has changed? Don't
>>>> the
>>>>>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Stephen Turner
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>> 
>>>>>>>>>>> I think this flow is something we should seriously consider.
>>>>>>>>>>> 
>>>>>>>>>>> I find cherry picking from branch to branch to be error prone in
>>>> that
>>>>>>>> it's
>>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
>>>> branches
>>>>>>>> and
>>>>>>>>>>> you don't have any easy way to see the cherry picks are related.
>>>>>>>>>>> 
>>>>>>>>>>> When I worked at HP, we had automated tools check to see if you
>>>>>>>> checked a
>>>>>>>>>>> fix into a prior release, but not later releases. In such a
>>>> situation,
>>>>>>>> you
>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
>>>>>>>> longer
>>>>>>>>>>> applicable in the later release(s), so you needed to mark it as
>>>>>>>>>>> un-necessary (SVN supported this ability...not sure about Git).
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Our current git workflow is confusing with the *forward branches
>>>> and
>>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the commit
>>>> has
>>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>>>> contributor, I
>>>>>>>>>>>> endup creating patches for each branch as it doesn’t cleanly
>>>> apply on
>>>>>>>>>>>> different branches.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> I think we should have some guidelines. Here is what I propose.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
>>>> 4.4.x,
>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly
>>>> on
>>>>>>>>>>>> the respective branches.
>>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many branches
>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
>>>>>>>>>>>> we have two physically distinct commits for the same change or
>>>> fix and
>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>>>> 4.  There should always be a continous flow from release branches
>>>> to
>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
>>>> merged(either
>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable
>>>> with
>>>>>>>>>>>> git branch --contains
>>>>>>>>>>>> *   Every bug fix should always flow from minimal release uptill
>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>>> *   If someone forgets to do the merge, the next time a new commit
>>>>>>>>>>> is
>>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>>> 5.  There should always be a continuous flow from master to
>>>> feature
>>>>>>>>>>>> branches. Meaning all feature branch owners should proactively
>>>> take
>>>>>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>>>>>> 6.  The commits from feature branch will make to master on code
>>>>>>>>>>>> complete through a merge.
>>>>>>>>>>>> 7.  There should never be a merge from master to release branches
>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>>>>>>>>>>>> should have atleast bug id and correct author information
>>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>>>>>>>> <committer>
>>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>>> 9.  Once the release branch is created(after code freeze), any bug
>>>>>>>>>>>> in jira can be marked with fix version current release(4.4) only
>>>> on
>>>>>>>>>>>> RM's approval and only they can go to the release branch.  This
>>>> can be
>>>>>>>>>>>> done through jira and with certain rules.(may be using jira vote?)
>>>>>>>>>>>> this would save the cherry-picking time and another branch
>>>>>>>> maintenance.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Ref:
>>>>>>>>>>>> 
>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>> 
>>>>>>>>>>>> ~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>*™*
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> *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: [DISCUSS][PROPOSAL] git workflow

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

Sebastien,

It seems we can do what you are calling for is creating a branch
called 'release'. We can merge back into that branch from 4.4, master,
4.3. I would like to see people that want a feature or bug fix in a
branch make a fork of that branch and when that fork is working do a
cherry-pick. The -forward concept is now used for that but it is
broken because more then for one piece of work there are commits on
it. This caused me conflicts during the release. Especially painfull
as not all was intended to get into the release. We can create this
'release' branch now on the basis of 4.4 and start pulling in changes.
There is a question of control. Do we allow all committers to manage
the release? I am for that but can imagine not everybody is.

rule number 1 will be: you are going to do something to the code, you
start by creating a branch.

right?

On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com> wrote:
>
>> Hey everyone,
>>
>> I've been a developer for a handful of years and have had my share of
>> experience with different version control systems.  I've used (for better
>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>
>> Each of these solutions offers their own unique set of features, strengths
>> and weaknesses.  As there are so many systems that are good at specific
>> things, it seems best to use the features that the chosen system is best at.
>>
>> Git is great at branching, merging and using that structure to maintain and
>> control how changes get into the primary branches.  Git tools even make
>> this easy by integrating directly into the "Gitflow" to make branching and
>> merging that much easier.  It would seem counter-intuitive to NOT make use
>> of these built-in capabilities.
>>
>> In addition to that, I know that the current method of change management is
>> incredibly frustrating to work with, and works directly against the way a
>> typical Git user would expect it to be structured.  I should NEVER have
>> problem compiling and running something on master.  I should not have
>> problems building anything on a release branch.  A feature/bugfix branch is
>> where things can be, and often are, broken or unstable.  There have been
>> many times working in Cloudstack where I've had to search for a stable
>> revision on master, and that's just plain wrong.
>>
>> I do realize that having this many developers working on so many features
>> and bugfixes will result in a large number of branches.  I don't believe
>> this is a good argument against using a branching method, though - I
>> believe that the current system is even more confusing and difficult to use.
>>
>> I could pontificate on change management quite a bit more, but my opinion
>> in summary would basically be:  use Git the way it was meant to be used,
>> and things will be better.  Just my two cents.
>>
>> Sam
>>
>>
>
> Sam, I think we are in agreement (at least with folks who responded to this thread).
> Or maybe I am not reading your mail right and you don't agree with Leo ?
>
> My own take and reason for calling for a change we are currently doing things is mostly due to the way we release.
>
> I would like to see a stable master (and I think we are in agreement with that).
> That means that development should not happen on master and that every commit that lands on master should be shippable.
>
> I personally have no issues with cherry-picking. So I would be fine cherry picking from a hot-fix branch into master, to fix a bug.
> The end result is that the next commit on master would still mean master is shippable/releasable.
>
> If we agree with this basic concept. The question becomes how do we get there, considering that master is now full of dev work and potential bug.
> The only releasable product we have are on the 4.3, 4.4 and previous release branches.
>
> Ideally, I would like to see master becomes 4.4. And work our way back, merging the new features that are already in master into the new master (based on 4.4).
> This could be quite complicated but we need to do it (or something like it).
>
> To move forward, we should make a proposal to the list and call for a vote.
>
> Any takers to start a wiki page proposing a new git process and how we could move to it (transition path) ?
>
>
> -Sebastien
>
>
>>
>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <LS...@schubergphilis.com>
>> wrote:
>>
>>> Hey folks,
>>>
>>> With 4.4.0 tagged, is now an opportune time to go and implement this?
>>>
>>> I would enthousiastically +1 and get crackin', but I’m not a committer so
>>> its not that practical for me to volunteer!
>>>
>>> I wanted to point out atlassian’s description of gitflow
>>>
>>>  https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>
>>> which might be easier to read.
>>>
>>> Similarly, the git-flow scripts that help out with implementing this stuff
>>>
>>>  https://github.com/nvie/gitflow
>>>
>>> they also describe the relationship between gitflow and dealing with
>>> multiple remotes
>>>
>>>  https://www.atlassian.com/git/workflows#!pull-request
>>>
>>> Finally note atlassian’s free sourcetree GUI has built-in support for
>>> git-flow
>>>
>>>  http://www.sourcetreeapp.com/
>>>
>>> Because cloudstack currently is full of rebasing and squashing and
>>> cherry-picking, you get very little benefit from a tree visualization tool
>>> (like this or gitk or ...) right now, but it would be *great* to have going
>>> forward.
>>>
>>>
>>> cheers,
>>>
>>>
>>> Leo
>>>
>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>>>
>>>> I would like to re-start this discussion.
>>>>
>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>
>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>
>>>> Thinking about our release procedure, we clearly need more tests and a
>>> CI. However it looks like this is going to take some time.
>>>>
>>>> In the meantime I think there is nothing preventing us from agreeing to
>>> 'git practices', we don't need tests or new infra, we just need to agree on
>>> the git workflow.
>>>>
>>>> Right now Master is really a development branch, we should make it a
>>> stable branch for production with very few commits.
>>>> This does not mean that we would release less, in contrary this would
>>> ensure that a commit to master means it's a production release.
>>>>
>>>> In addition gitflow [1] does not do cherry-picks (gets back to Rajani's
>>> point) everything is based on merges.
>>>>
>>>> I am of the opinion that git flow provides a nice process. It basically
>>> freezes master. Development happens in a 'develop' branch, releases
>>> branches are branched off of that and merged into master and back into
>>> develop….etc
>>>>
>>>> Please read [1] it's a good read.
>>>>
>>>> And let's discuss,
>>>>
>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>>>
>>>> -Sebastien
>>>>
>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Ra...@citrix.com>
>>> wrote:
>>>>
>>>>> There is also the problem of cherry-picking.
>>>>> As a contributor, I always endup creating multiple patches for each
>>> branch as they don’t cleanly apply on the upward branches. which means
>>> distinct commits for each branch and I don’t easily know which all branches
>>> my commit exists unless I do grep.
>>>>> if we follow merging strategy properly, apart from the first merge of
>>> the branch, everything else on top of it should be a painless merge.
>>>>>
>>>>>
>>>>>
>>>>> ~Rajani
>>>>>
>>>>>
>>>>>
>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
>>>>>
>>>>>> I think many of the bullet points are what we are currently doing
>>>>>> (guidelines for commit comments, feature branches need to stay in sync
>>> with
>>>>>> master, no back-merging). I also think that much of what we do now is
>>> done
>>>>>> the way it is simply because there *are* vast changes between versions.
>>>>>> Classes are getting shuffled around and changed all the time. If its
>>>>>> feasible to merge branch fixes to master, that's fine, but some quick
>>> tests
>>>>>> seem to indicate that this will be messy getting started.
>>>>>>
>>>>>> That leaves us with how we do releases. I'm fine with having single
>>>>>> branches for major releases(4.3) and tagging the commits where each
>>>>>> incremental release (4.3.x) is done. I'm trying to remember why we went
>>>>>> with the -forward, I'm sure it's in the mailing list somewhere, but
>>> one of
>>>>>> the nice things it provides is the ability for the release manager to
>>>>>> control what changes are made during code freeze while giving people a
>>>>>> place to stage fixes (though admittedly this is not always followed).
>>>>>> Without -forward, would the flow be for each dev to have their own
>>> repo and
>>>>>> issue pull requests for bugfixes?
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>> Rajani.Karuturi@citrix.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Any other suggestions/objections/comments??
>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>
>>>>>>>
>>>>>>> ~Rajani
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>> Rajani.Karuturi@citrix.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>>> merge(merge -s
>>>>>>> ours) for it and git will assume its merged but will not bring in any
>>>>>>> changes.
>>>>>>>>
>>>>>>>> If the branches diverged a lot, for example after a major rewrite, we
>>>>>>> could stop merging to that branch and above and make the fix manually.
>>>>>>>>
>>>>>>>>
>>>>>>>> ~Rajani
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>
>>>>>>>>> Yep, that's what I was referring to in that a particular fix for an
>>> old
>>>>>>>>> release may not apply to newer versions. That does happen.
>>>>>>>>>
>>>>>>>>> We used to mark those as "don't need to merge to branch x" in SVN
>>> and
>>>>>>> then
>>>>>>>>> you handed it however made sense on the applicable branch(es).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or has to
>>> be
>>>>>>>>>> rewritten for newer versions because the code has changed? Don't
>>> the
>>>>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Stephen Turner
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>
>>>>>>>>>> I think this flow is something we should seriously consider.
>>>>>>>>>>
>>>>>>>>>> I find cherry picking from branch to branch to be error prone in
>>> that
>>>>>>> it's
>>>>>>>>>> easy for someone to forget to cherry pick to all applicable
>>> branches
>>>>>>> and
>>>>>>>>>> you don't have any easy way to see the cherry picks are related.
>>>>>>>>>>
>>>>>>>>>> When I worked at HP, we had automated tools check to see if you
>>>>>>> checked a
>>>>>>>>>> fix into a prior release, but not later releases. In such a
>>> situation,
>>>>>>> you
>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
>>>>>>> longer
>>>>>>>>>> applicable in the later release(s), so you needed to mark it as
>>>>>>>>>> un-necessary (SVN supported this ability...not sure about Git).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Our current git workflow is confusing with the *forward branches
>>> and
>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the commit
>>> has
>>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>>> contributor, I
>>>>>>>>>>> endup creating patches for each branch as it doesn’t cleanly
>>> apply on
>>>>>>>>>>> different branches.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think we should have some guidelines. Here is what I propose.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
>>> 4.4.x,
>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly
>>> on
>>>>>>>>>>> the respective branches.
>>>>>>>>>>> 2.  The branch naming convention is to be followed. Many branches
>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
>>>>>>>>>>> we have two physically distinct commits for the same change or
>>> fix and
>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>>> 4.  There should always be a continous flow from release branches
>>> to
>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
>>> merged(either
>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable
>>> with
>>>>>>>>>>> git branch --contains
>>>>>>>>>>> *   Every bug fix should always flow from minimal release uptill
>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>> *   If someone forgets to do the merge, the next time a new commit
>>>>>>>>>> is
>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>> 5.  There should always be a continuous flow from master to
>>> feature
>>>>>>>>>>> branches. Meaning all feature branch owners should proactively
>>> take
>>>>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>>>>> 6.  The commits from feature branch will make to master on code
>>>>>>>>>>> complete through a merge.
>>>>>>>>>>> 7.  There should never be a merge from master to release branches
>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>>>>>>>>>>> should have atleast bug id and correct author information
>>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>>>>>>> <committer>
>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>> 9.  Once the release branch is created(after code freeze), any bug
>>>>>>>>>>> in jira can be marked with fix version current release(4.4) only
>>> on
>>>>>>>>>>> RM's approval and only they can go to the release branch.  This
>>> can be
>>>>>>>>>>> done through jira and with certain rules.(may be using jira vote?)
>>>>>>>>>>> this would save the cherry-picking time and another branch
>>>>>>> maintenance.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ref:
>>>>>>>>>>>
>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>
>>>>>>>>>>> ~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>*™*
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *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: [DISCUSS][PROPOSAL] git workflow

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

On Jul 23, 2014, at 11:19 AM, Sam Schmit <sa...@appcore.com> wrote:

> Hey everyone,
> 
> I've been a developer for a handful of years and have had my share of
> experience with different version control systems.  I've used (for better
> or worse) Git, Perforce, Rational ClearCast, and SVN.
> 
> Each of these solutions offers their own unique set of features, strengths
> and weaknesses.  As there are so many systems that are good at specific
> things, it seems best to use the features that the chosen system is best at.
> 
> Git is great at branching, merging and using that structure to maintain and
> control how changes get into the primary branches.  Git tools even make
> this easy by integrating directly into the "Gitflow" to make branching and
> merging that much easier.  It would seem counter-intuitive to NOT make use
> of these built-in capabilities.
> 
> In addition to that, I know that the current method of change management is
> incredibly frustrating to work with, and works directly against the way a
> typical Git user would expect it to be structured.  I should NEVER have
> problem compiling and running something on master.  I should not have
> problems building anything on a release branch.  A feature/bugfix branch is
> where things can be, and often are, broken or unstable.  There have been
> many times working in Cloudstack where I've had to search for a stable
> revision on master, and that's just plain wrong.
> 
> I do realize that having this many developers working on so many features
> and bugfixes will result in a large number of branches.  I don't believe
> this is a good argument against using a branching method, though - I
> believe that the current system is even more confusing and difficult to use.
> 
> I could pontificate on change management quite a bit more, but my opinion
> in summary would basically be:  use Git the way it was meant to be used,
> and things will be better.  Just my two cents.
> 
> Sam
> 
> 

Sam, I think we are in agreement (at least with folks who responded to this thread).
Or maybe I am not reading your mail right and you don't agree with Leo ?

My own take and reason for calling for a change we are currently doing things is mostly due to the way we release.

I would like to see a stable master (and I think we are in agreement with that).
That means that development should not happen on master and that every commit that lands on master should be shippable.

I personally have no issues with cherry-picking. So I would be fine cherry picking from a hot-fix branch into master, to fix a bug. 
The end result is that the next commit on master would still mean master is shippable/releasable.

If we agree with this basic concept. The question becomes how do we get there, considering that master is now full of dev work and potential bug.
The only releasable product we have are on the 4.3, 4.4 and previous release branches.

Ideally, I would like to see master becomes 4.4. And work our way back, merging the new features that are already in master into the new master (based on 4.4).
This could be quite complicated but we need to do it (or something like it).

To move forward, we should make a proposal to the list and call for a vote.

Any takers to start a wiki page proposing a new git process and how we could move to it (transition path) ?


-Sebastien


> 
> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <LS...@schubergphilis.com>
> wrote:
> 
>> Hey folks,
>> 
>> With 4.4.0 tagged, is now an opportune time to go and implement this?
>> 
>> I would enthousiastically +1 and get crackin', but I’m not a committer so
>> its not that practical for me to volunteer!
>> 
>> I wanted to point out atlassian’s description of gitflow
>> 
>>  https://www.atlassian.com/git/workflows#!workflow-gitflow
>> 
>> which might be easier to read.
>> 
>> Similarly, the git-flow scripts that help out with implementing this stuff
>> 
>>  https://github.com/nvie/gitflow
>> 
>> they also describe the relationship between gitflow and dealing with
>> multiple remotes
>> 
>>  https://www.atlassian.com/git/workflows#!pull-request
>> 
>> Finally note atlassian’s free sourcetree GUI has built-in support for
>> git-flow
>> 
>>  http://www.sourcetreeapp.com/
>> 
>> Because cloudstack currently is full of rebasing and squashing and
>> cherry-picking, you get very little benefit from a tree visualization tool
>> (like this or gitk or ...) right now, but it would be *great* to have going
>> forward.
>> 
>> 
>> cheers,
>> 
>> 
>> Leo
>> 
>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>> 
>>> I would like to re-start this discussion.
>>> 
>>> Rajani made some good points and someone mentioned Gitflow:
>>> 
>>> http://nvie.com/posts/a-successful-git-branching-model/
>>> 
>>> Thinking about our release procedure, we clearly need more tests and a
>> CI. However it looks like this is going to take some time.
>>> 
>>> In the meantime I think there is nothing preventing us from agreeing to
>> 'git practices', we don't need tests or new infra, we just need to agree on
>> the git workflow.
>>> 
>>> Right now Master is really a development branch, we should make it a
>> stable branch for production with very few commits.
>>> This does not mean that we would release less, in contrary this would
>> ensure that a commit to master means it's a production release.
>>> 
>>> In addition gitflow [1] does not do cherry-picks (gets back to Rajani's
>> point) everything is based on merges.
>>> 
>>> I am of the opinion that git flow provides a nice process. It basically
>> freezes master. Development happens in a 'develop' branch, releases
>> branches are branched off of that and merged into master and back into
>> develop….etc
>>> 
>>> Please read [1] it's a good read.
>>> 
>>> And let's discuss,
>>> 
>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>> 
>>> -Sebastien
>>> 
>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Ra...@citrix.com>
>> wrote:
>>> 
>>>> There is also the problem of cherry-picking.
>>>> As a contributor, I always endup creating multiple patches for each
>> branch as they don’t cleanly apply on the upward branches. which means
>> distinct commits for each branch and I don’t easily know which all branches
>> my commit exists unless I do grep.
>>>> if we follow merging strategy properly, apart from the first merge of
>> the branch, everything else on top of it should be a painless merge.
>>>> 
>>>> 
>>>> 
>>>> ~Rajani
>>>> 
>>>> 
>>>> 
>>>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
>>>> 
>>>>> I think many of the bullet points are what we are currently doing
>>>>> (guidelines for commit comments, feature branches need to stay in sync
>> with
>>>>> master, no back-merging). I also think that much of what we do now is
>> done
>>>>> the way it is simply because there *are* vast changes between versions.
>>>>> Classes are getting shuffled around and changed all the time. If its
>>>>> feasible to merge branch fixes to master, that's fine, but some quick
>> tests
>>>>> seem to indicate that this will be messy getting started.
>>>>> 
>>>>> That leaves us with how we do releases. I'm fine with having single
>>>>> branches for major releases(4.3) and tagging the commits where each
>>>>> incremental release (4.3.x) is done. I'm trying to remember why we went
>>>>> with the -forward, I'm sure it's in the mailing list somewhere, but
>> one of
>>>>> the nice things it provides is the ability for the release manager to
>>>>> control what changes are made during code freeze while giving people a
>>>>> place to stage fixes (though admittedly this is not always followed).
>>>>> Without -forward, would the flow be for each dev to have their own
>> repo and
>>>>> issue pull requests for bugfixes?
>>>>> 
>>>>> 
>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>> Rajani.Karuturi@citrix.com>
>>>>> wrote:
>>>>> 
>>>>>> Any other suggestions/objections/comments??
>>>>>> Can we discuss this in detail and agree to a process??
>>>>>> 
>>>>>> 
>>>>>> ~Rajani
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>> Rajani.Karuturi@citrix.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>> merge(merge -s
>>>>>> ours) for it and git will assume its merged but will not bring in any
>>>>>> changes.
>>>>>>> 
>>>>>>> If the branches diverged a lot, for example after a major rewrite, we
>>>>>> could stop merging to that branch and above and make the fix manually.
>>>>>>> 
>>>>>>> 
>>>>>>> ~Rajani
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>> 
>>>>>>>> Yep, that's what I was referring to in that a particular fix for an
>> old
>>>>>>>> release may not apply to newer versions. That does happen.
>>>>>>>> 
>>>>>>>> We used to mark those as "don't need to merge to branch x" in SVN
>> and
>>>>>> then
>>>>>>>> you handed it however made sense on the applicable branch(es).
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>>>> Stephen.Turner@citrix.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> What happens if a fix isn't relevant for newer versions, or has to
>> be
>>>>>>>>> rewritten for newer versions because the code has changed? Don't
>> the
>>>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Stephen Turner
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>> 
>>>>>>>>> I think this flow is something we should seriously consider.
>>>>>>>>> 
>>>>>>>>> I find cherry picking from branch to branch to be error prone in
>> that
>>>>>> it's
>>>>>>>>> easy for someone to forget to cherry pick to all applicable
>> branches
>>>>>> and
>>>>>>>>> you don't have any easy way to see the cherry picks are related.
>>>>>>>>> 
>>>>>>>>> When I worked at HP, we had automated tools check to see if you
>>>>>> checked a
>>>>>>>>> fix into a prior release, but not later releases. In such a
>> situation,
>>>>>> you
>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
>>>>>> longer
>>>>>>>>> applicable in the later release(s), so you needed to mark it as
>>>>>>>>> un-necessary (SVN supported this ability...not sure about Git).
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>> 
>>>>>>>>>> Hi all,
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Our current git workflow is confusing with the *forward branches
>> and
>>>>>>>>>> cherry-picking. Its hard to track on what all releases the commit
>> has
>>>>>>>>>> gone into unless I do some git log greping. Also, as a
>> contributor, I
>>>>>>>>>> endup creating patches for each branch as it doesn’t cleanly
>> apply on
>>>>>>>>>> different branches.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I think we should have some guidelines. Here is what I propose.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
>> 4.4.x,
>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly
>> on
>>>>>>>>>> the respective branches.
>>>>>>>>>> 2.  The branch naming convention is to be followed. Many branches
>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
>>>>>>>>>> we have two physically distinct commits for the same change or
>> fix and
>>>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>>>> 4.  There should always be a continous flow from release branches
>> to
>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be
>> merged(either
>>>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable
>> with
>>>>>>>>>> git branch --contains
>>>>>>>>>> *   Every bug fix should always flow from minimal release uptill
>>>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>> *   If someone forgets to do the merge, the next time a new commit
>>>>>>>>> is
>>>>>>>>>> done this will also get merged.
>>>>>>>>>> 5.  There should always be a continuous flow from master to
>> feature
>>>>>>>>>> branches. Meaning all feature branch owners should proactively
>> take
>>>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>>>> 6.  The commits from feature branch will make to master on code
>>>>>>>>>> complete through a merge.
>>>>>>>>>> 7.  There should never be a merge from master to release branches
>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>>>>>>>>>> should have atleast bug id and correct author information
>>>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>>>>>> <committer>
>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>> 9.  Once the release branch is created(after code freeze), any bug
>>>>>>>>>> in jira can be marked with fix version current release(4.4) only
>> on
>>>>>>>>>> RM's approval and only they can go to the release branch.  This
>> can be
>>>>>>>>>> done through jira and with certain rules.(may be using jira vote?)
>>>>>>>>>> this would save the cherry-picking time and another branch
>>>>>> maintenance.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Ref:
>>>>>>>>>> 
>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>> 
>>>>>>>>>> ~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>*™*
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> *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: [DISCUSS][PROPOSAL] git workflow

[Sam Schmit <sa...@appcore.com>]

Hey everyone,

I've been a developer for a handful of years and have had my share of
experience with different version control systems.  I've used (for better
or worse) Git, Perforce, Rational ClearCast, and SVN.

Each of these solutions offers their own unique set of features, strengths
and weaknesses.  As there are so many systems that are good at specific
things, it seems best to use the features that the chosen system is best at.

Git is great at branching, merging and using that structure to maintain and
control how changes get into the primary branches.  Git tools even make
this easy by integrating directly into the "Gitflow" to make branching and
merging that much easier.  It would seem counter-intuitive to NOT make use
of these built-in capabilities.

In addition to that, I know that the current method of change management is
incredibly frustrating to work with, and works directly against the way a
typical Git user would expect it to be structured.  I should NEVER have
problem compiling and running something on master.  I should not have
problems building anything on a release branch.  A feature/bugfix branch is
where things can be, and often are, broken or unstable.  There have been
many times working in Cloudstack where I've had to search for a stable
revision on master, and that's just plain wrong.

I do realize that having this many developers working on so many features
and bugfixes will result in a large number of branches.  I don't believe
this is a good argument against using a branching method, though - I
believe that the current system is even more confusing and difficult to use.

I could pontificate on change management quite a bit more, but my opinion
in summary would basically be:  use Git the way it was meant to be used,
and things will be better.  Just my two cents.

Sam



On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <LS...@schubergphilis.com>
wrote:

> Hey folks,
>
> With 4.4.0 tagged, is now an opportune time to go and implement this?
>
> I would enthousiastically +1 and get crackin', but I’m not a committer so
> its not that practical for me to volunteer!
>
> I wanted to point out atlassian’s description of gitflow
>
>   https://www.atlassian.com/git/workflows#!workflow-gitflow
>
> which might be easier to read.
>
> Similarly, the git-flow scripts that help out with implementing this stuff
>
>   https://github.com/nvie/gitflow
>
> they also describe the relationship between gitflow and dealing with
> multiple remotes
>
>   https://www.atlassian.com/git/workflows#!pull-request
>
> Finally note atlassian’s free sourcetree GUI has built-in support for
> git-flow
>
>   http://www.sourcetreeapp.com/
>
> Because cloudstack currently is full of rebasing and squashing and
> cherry-picking, you get very little benefit from a tree visualization tool
> (like this or gitk or ...) right now, but it would be *great* to have going
> forward.
>
>
> cheers,
>
>
> Leo
>
> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> > I would like to re-start this discussion.
> >
> > Rajani made some good points and someone mentioned Gitflow:
> >
> > http://nvie.com/posts/a-successful-git-branching-model/
> >
> > Thinking about our release procedure, we clearly need more tests and a
> CI. However it looks like this is going to take some time.
> >
> > In the meantime I think there is nothing preventing us from agreeing to
> 'git practices', we don't need tests or new infra, we just need to agree on
> the git workflow.
> >
> > Right now Master is really a development branch, we should make it a
> stable branch for production with very few commits.
> > This does not mean that we would release less, in contrary this would
> ensure that a commit to master means it's a production release.
> >
> > In addition gitflow [1] does not do cherry-picks (gets back to Rajani's
> point) everything is based on merges.
> >
> > I am of the opinion that git flow provides a nice process. It basically
> freezes master. Development happens in a 'develop' branch, releases
> branches are branched off of that and merged into master and back into
> develop….etc
> >
> > Please read [1] it's a good read.
> >
> > And let's discuss,
> >
> > [1] http://nvie.com/posts/a-successful-git-branching-model/
> >
> > -Sebastien
> >
> > On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Ra...@citrix.com>
> wrote:
> >
> >> There is also the problem of cherry-picking.
> >> As a contributor, I always endup creating multiple patches for each
> branch as they don’t cleanly apply on the upward branches. which means
> distinct commits for each branch and I don’t easily know which all branches
> my commit exists unless I do grep.
> >> if we follow merging strategy properly, apart from the first merge of
> the branch, everything else on top of it should be a painless merge.
> >>
> >>
> >>
> >> ~Rajani
> >>
> >>
> >>
> >> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
> >>
> >>> I think many of the bullet points are what we are currently doing
> >>> (guidelines for commit comments, feature branches need to stay in sync
> with
> >>> master, no back-merging). I also think that much of what we do now is
> done
> >>> the way it is simply because there *are* vast changes between versions.
> >>> Classes are getting shuffled around and changed all the time. If its
> >>> feasible to merge branch fixes to master, that's fine, but some quick
> tests
> >>> seem to indicate that this will be messy getting started.
> >>>
> >>> That leaves us with how we do releases. I'm fine with having single
> >>> branches for major releases(4.3) and tagging the commits where each
> >>> incremental release (4.3.x) is done. I'm trying to remember why we went
> >>> with the -forward, I'm sure it's in the mailing list somewhere, but
> one of
> >>> the nice things it provides is the ability for the release manager to
> >>> control what changes are made during code freeze while giving people a
> >>> place to stage fixes (though admittedly this is not always followed).
> >>> Without -forward, would the flow be for each dev to have their own
> repo and
> >>> issue pull requests for bugfixes?
> >>>
> >>>
> >>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> Rajani.Karuturi@citrix.com>
> >>> wrote:
> >>>
> >>>> Any other suggestions/objections/comments??
> >>>> Can we discuss this in detail and agree to a process??
> >>>>
> >>>>
> >>>> ~Rajani
> >>>>
> >>>>
> >>>>
> >>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> Rajani.Karuturi@citrix.com>
> >>>> wrote:
> >>>>
> >>>>> Yes as mike said, if its a one-off case we can do a empty
> merge(merge -s
> >>>> ours) for it and git will assume its merged but will not bring in any
> >>>> changes.
> >>>>>
> >>>>> If the branches diverged a lot, for example after a major rewrite, we
> >>>> could stop merging to that branch and above and make the fix manually.
> >>>>>
> >>>>>
> >>>>> ~Rajani
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>
> >>>>>> Yep, that's what I was referring to in that a particular fix for an
> old
> >>>>>> release may not apply to newer versions. That does happen.
> >>>>>>
> >>>>>> We used to mark those as "don't need to merge to branch x" in SVN
> and
> >>>> then
> >>>>>> you handed it however made sense on the applicable branch(es).
> >>>>>>
> >>>>>>
> >>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>>> Stephen.Turner@citrix.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> What happens if a fix isn't relevant for newer versions, or has to
> be
> >>>>>>> rewritten for newer versions because the code has changed? Don't
> the
> >>>>>>> branches diverge and you end up cherry-picking after that?
> >>>>>>>
> >>>>>>> --
> >>>>>>> Stephen Turner
> >>>>>>>
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> >>>>>>> Sent: 30 May 2014 18:48
> >>>>>>> To: dev@cloudstack.apache.org
> >>>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>>
> >>>>>>> I think this flow is something we should seriously consider.
> >>>>>>>
> >>>>>>> I find cherry picking from branch to branch to be error prone in
> that
> >>>> it's
> >>>>>>> easy for someone to forget to cherry pick to all applicable
> branches
> >>>> and
> >>>>>>> you don't have any easy way to see the cherry picks are related.
> >>>>>>>
> >>>>>>> When I worked at HP, we had automated tools check to see if you
> >>>> checked a
> >>>>>>> fix into a prior release, but not later releases. In such a
> situation,
> >>>> you
> >>>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
> >>>> longer
> >>>>>>> applicable in the later release(s), so you needed to mark it as
> >>>>>>> un-necessary (SVN supported this ability...not sure about Git).
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>>
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Our current git workflow is confusing with the *forward branches
> and
> >>>>>>>> cherry-picking. Its hard to track on what all releases the commit
> has
> >>>>>>>> gone into unless I do some git log greping. Also, as a
> contributor, I
> >>>>>>>> endup creating patches for each branch as it doesn’t cleanly
> apply on
> >>>>>>>> different branches.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I think we should have some guidelines. Here is what I propose.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x,
> 4.4.x,
> >>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly
> on
> >>>>>>>> the respective branches.
> >>>>>>>> 2.  The branch naming convention is to be followed. Many branches
> >>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
> >>>>>>>> we have two physically distinct commits for the same change or
> fix and
> >>>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>>> 4.  There should always be a continous flow from release branches
> to
> >>>>>>>> master. This doesn’t mean cherry-picking. They should be
> merged(either
> >>>>>>>> ff or no-ff) which retains the commit ids and easily trackable
> with
> >>>>>>>> git branch --contains
> >>>>>>>> *   Every bug fix should always flow from minimal release uptill
> >>>>>>>> master. A bug isnt fixed until the fix reaches master.
> >>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> >>>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>> *   If someone forgets to do the merge, the next time a new commit
> >>>>>>> is
> >>>>>>>> done this will also get merged.
> >>>>>>>> 5.  There should always be a continuous flow from master to
> feature
> >>>>>>>> branches. Meaning all feature branch owners should proactively
> take
> >>>>>>>> any new commits from master by doing a merge from master
> >>>>>>>> 6.  The commits from feature branch will make to master on code
> >>>>>>>> complete through a merge.
> >>>>>>>> 7.  There should never be a merge from master to release branches
> >>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
> >>>>>>>> should have atleast bug id and correct author information
> >>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
> >>>> <committer>
> >>>>>>>> for CASSANDRA-<ticket>
> >>>>>>>> 9.  Once the release branch is created(after code freeze), any bug
> >>>>>>>> in jira can be marked with fix version current release(4.4) only
> on
> >>>>>>>> RM's approval and only they can go to the release branch.  This
> can be
> >>>>>>>> done through jira and with certain rules.(may be using jira vote?)
> >>>>>>>> this would save the cherry-picking time and another branch
> >>>> maintenance.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Ref:
> >>>>>>>>
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>>
> >>>>>>>> ~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>*™*
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> *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: [DISCUSS][PROPOSAL] git workflow

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

Hey folks,

With 4.4.0 tagged, is now an opportune time to go and implement this?

I would enthousiastically +1 and get crackin', but I’m not a committer so its not that practical for me to volunteer!

I wanted to point out atlassian’s description of gitflow

  https://www.atlassian.com/git/workflows#!workflow-gitflow

which might be easier to read.

Similarly, the git-flow scripts that help out with implementing this stuff

  https://github.com/nvie/gitflow

they also describe the relationship between gitflow and dealing with multiple remotes

  https://www.atlassian.com/git/workflows#!pull-request

Finally note atlassian’s free sourcetree GUI has built-in support for git-flow

  http://www.sourcetreeapp.com/

Because cloudstack currently is full of rebasing and squashing and cherry-picking, you get very little benefit from a tree visualization tool (like this or gitk or ...) right now, but it would be *great* to have going forward.


cheers,


Leo

On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <ru...@gmail.com> wrote:

> I would like to re-start this discussion.
> 
> Rajani made some good points and someone mentioned Gitflow:
> 
> http://nvie.com/posts/a-successful-git-branching-model/
> 
> Thinking about our release procedure, we clearly need more tests and a CI. However it looks like this is going to take some time.
> 
> In the meantime I think there is nothing preventing us from agreeing to 'git practices', we don't need tests or new infra, we just need to agree on the git workflow.
> 
> Right now Master is really a development branch, we should make it a stable branch for production with very few commits.
> This does not mean that we would release less, in contrary this would ensure that a commit to master means it's a production release.
> 
> In addition gitflow [1] does not do cherry-picks (gets back to Rajani's point) everything is based on merges.
> 
> I am of the opinion that git flow provides a nice process. It basically freezes master. Development happens in a 'develop' branch, releases branches are branched off of that and merged into master and back into develop….etc
> 
> Please read [1] it's a good read.
> 
> And let's discuss,
> 
> [1] http://nvie.com/posts/a-successful-git-branching-model/
> 
> -Sebastien
> 
> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Ra...@citrix.com> wrote:
> 
>> There is also the problem of cherry-picking.
>> As a contributor, I always endup creating multiple patches for each branch as they don’t cleanly apply on the upward branches. which means distinct commits for each branch and I don’t easily know which all branches my commit exists unless I do grep.
>> if we follow merging strategy properly, apart from the first merge of the branch, everything else on top of it should be a painless merge. 
>> 
>> 
>> 
>> ~Rajani
>> 
>> 
>> 
>> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
>> 
>>> I think many of the bullet points are what we are currently doing
>>> (guidelines for commit comments, feature branches need to stay in sync with
>>> master, no back-merging). I also think that much of what we do now is done
>>> the way it is simply because there *are* vast changes between versions.
>>> Classes are getting shuffled around and changed all the time. If its
>>> feasible to merge branch fixes to master, that's fine, but some quick tests
>>> seem to indicate that this will be messy getting started.
>>> 
>>> That leaves us with how we do releases. I'm fine with having single
>>> branches for major releases(4.3) and tagging the commits where each
>>> incremental release (4.3.x) is done. I'm trying to remember why we went
>>> with the -forward, I'm sure it's in the mailing list somewhere, but one of
>>> the nice things it provides is the ability for the release manager to
>>> control what changes are made during code freeze while giving people a
>>> place to stage fixes (though admittedly this is not always followed).
>>> Without -forward, would the flow be for each dev to have their own repo and
>>> issue pull requests for bugfixes?
>>> 
>>> 
>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <Ra...@citrix.com>
>>> wrote:
>>> 
>>>> Any other suggestions/objections/comments??
>>>> Can we discuss this in detail and agree to a process??
>>>> 
>>>> 
>>>> ~Rajani
>>>> 
>>>> 
>>>> 
>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <Ra...@citrix.com>
>>>> wrote:
>>>> 
>>>>> Yes as mike said, if its a one-off case we can do a empty merge(merge -s
>>>> ours) for it and git will assume its merged but will not bring in any
>>>> changes.
>>>>> 
>>>>> If the branches diverged a lot, for example after a major rewrite, we
>>>> could stop merging to that branch and above and make the fix manually.
>>>>> 
>>>>> 
>>>>> ~Rajani
>>>>> 
>>>>> 
>>>>> 
>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>> mike.tutkowski@solidfire.com> wrote:
>>>>> 
>>>>>> Yep, that's what I was referring to in that a particular fix for an old
>>>>>> release may not apply to newer versions. That does happen.
>>>>>> 
>>>>>> We used to mark those as "don't need to merge to branch x" in SVN and
>>>> then
>>>>>> you handed it however made sense on the applicable branch(es).
>>>>>> 
>>>>>> 
>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>>> Stephen.Turner@citrix.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> What happens if a fix isn't relevant for newer versions, or has to be
>>>>>>> rewritten for newer versions because the code has changed? Don't the
>>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>>> 
>>>>>>> --
>>>>>>> Stephen Turner
>>>>>>> 
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>> Sent: 30 May 2014 18:48
>>>>>>> To: dev@cloudstack.apache.org
>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>> 
>>>>>>> I think this flow is something we should seriously consider.
>>>>>>> 
>>>>>>> I find cherry picking from branch to branch to be error prone in that
>>>> it's
>>>>>>> easy for someone to forget to cherry pick to all applicable branches
>>>> and
>>>>>>> you don't have any easy way to see the cherry picks are related.
>>>>>>> 
>>>>>>> When I worked at HP, we had automated tools check to see if you
>>>> checked a
>>>>>>> fix into a prior release, but not later releases. In such a situation,
>>>> you
>>>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
>>>> longer
>>>>>>> applicable in the later release(s), so you needed to mark it as
>>>>>>> un-necessary (SVN supported this ability...not sure about Git).
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Our current git workflow is confusing with the *forward branches and
>>>>>>>> cherry-picking. Its hard to track on what all releases the commit has
>>>>>>>> gone into unless I do some git log greping. Also, as a contributor, I
>>>>>>>> endup creating patches for each branch as it doesn’t cleanly apply on
>>>>>>>> different branches.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I think we should have some guidelines. Here is what I propose.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x, 4.4.x,
>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on
>>>>>>>> the respective branches.
>>>>>>>> 2.  The branch naming convention is to be followed. Many branches
>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
>>>>>>>> we have two physically distinct commits for the same change or fix and
>>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>>> 4.  There should always be a continous flow from release branches to
>>>>>>>> master. This doesn’t mean cherry-picking. They should be merged(either
>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable with
>>>>>>>> git branch --contains
>>>>>>>> *   Every bug fix should always flow from minimal release uptill
>>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>> *   If someone forgets to do the merge, the next time a new commit
>>>>>>> is
>>>>>>>> done this will also get merged.
>>>>>>>> 5.  There should always be a continuous flow from master to feature
>>>>>>>> branches. Meaning all feature branch owners should proactively take
>>>>>>>> any new commits from master by doing a merge from master
>>>>>>>> 6.  The commits from feature branch will make to master on code
>>>>>>>> complete through a merge.
>>>>>>>> 7.  There should never be a merge from master to release branches
>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>>>>>>>> should have atleast bug id and correct author information
>>>>>>>> *   Cassandra's template: patch by <author>; reviewed by
>>>> <committer>
>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>> 9.  Once the release branch is created(after code freeze), any bug
>>>>>>>> in jira can be marked with fix version current release(4.4) only on
>>>>>>>> RM's approval and only they can go to the release branch.  This can be
>>>>>>>> done through jira and with certain rules.(may be using jira vote?)
>>>>>>>> this would save the cherry-picking time and another branch
>>>> maintenance.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Ref:
>>>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>> 
>>>>>>>> ~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>*™*
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> *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: [DISCUSS][PROPOSAL] git workflow

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

I would like to re-start this discussion.

Rajani made some good points and someone mentioned Gitflow:

http://nvie.com/posts/a-successful-git-branching-model/

Thinking about our release procedure, we clearly need more tests and a CI. However it looks like this is going to take some time.

In the meantime I think there is nothing preventing us from agreeing to 'git practices', we don't need tests or new infra, we just need to agree on the git workflow.

Right now Master is really a development branch, we should make it a stable branch for production with very few commits.
This does not mean that we would release less, in contrary this would ensure that a commit to master means it's a production release.

In addition gitflow [1] does not do cherry-picks (gets back to Rajani's point) everything is based on merges.

I am of the opinion that git flow provides a nice process. It basically freezes master. Development happens in a 'develop' branch, releases branches are branched off of that and merged into master and back into develop….etc

Please read [1] it's a good read.

And let's discuss,

[1] http://nvie.com/posts/a-successful-git-branching-model/

-Sebastien

On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Ra...@citrix.com> wrote:

> There is also the problem of cherry-picking.
> As a contributor, I always endup creating multiple patches for each branch as they don’t cleanly apply on the upward branches. which means distinct commits for each branch and I don’t easily know which all branches my commit exists unless I do grep.
> if we follow merging strategy properly, apart from the first merge of the branch, everything else on top of it should be a painless merge. 
> 
> 
> 
> ~Rajani
> 
> 
> 
> On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:
> 
>> I think many of the bullet points are what we are currently doing
>> (guidelines for commit comments, feature branches need to stay in sync with
>> master, no back-merging). I also think that much of what we do now is done
>> the way it is simply because there *are* vast changes between versions.
>> Classes are getting shuffled around and changed all the time. If its
>> feasible to merge branch fixes to master, that's fine, but some quick tests
>> seem to indicate that this will be messy getting started.
>> 
>> That leaves us with how we do releases. I'm fine with having single
>> branches for major releases(4.3) and tagging the commits where each
>> incremental release (4.3.x) is done. I'm trying to remember why we went
>> with the -forward, I'm sure it's in the mailing list somewhere, but one of
>> the nice things it provides is the ability for the release manager to
>> control what changes are made during code freeze while giving people a
>> place to stage fixes (though admittedly this is not always followed).
>> Without -forward, would the flow be for each dev to have their own repo and
>> issue pull requests for bugfixes?
>> 
>> 
>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <Ra...@citrix.com>
>> wrote:
>> 
>>> Any other suggestions/objections/comments??
>>> Can we discuss this in detail and agree to a process??
>>> 
>>> 
>>> ~Rajani
>>> 
>>> 
>>> 
>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <Ra...@citrix.com>
>>> wrote:
>>> 
>>>> Yes as mike said, if its a one-off case we can do a empty merge(merge -s
>>> ours) for it and git will assume its merged but will not bring in any
>>> changes.
>>>> 
>>>> If the branches diverged a lot, for example after a major rewrite, we
>>> could stop merging to that branch and above and make the fix manually.
>>>> 
>>>> 
>>>> ~Rajani
>>>> 
>>>> 
>>>> 
>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com> wrote:
>>>> 
>>>>> Yep, that's what I was referring to in that a particular fix for an old
>>>>> release may not apply to newer versions. That does happen.
>>>>> 
>>>>> We used to mark those as "don't need to merge to branch x" in SVN and
>>> then
>>>>> you handed it however made sense on the applicable branch(es).
>>>>> 
>>>>> 
>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>> Stephen.Turner@citrix.com>
>>>>> wrote:
>>>>> 
>>>>>> What happens if a fix isn't relevant for newer versions, or has to be
>>>>>> rewritten for newer versions because the code has changed? Don't the
>>>>>> branches diverge and you end up cherry-picking after that?
>>>>>> 
>>>>>> --
>>>>>> Stephen Turner
>>>>>> 
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>> Sent: 30 May 2014 18:48
>>>>>> To: dev@cloudstack.apache.org
>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>> 
>>>>>> I think this flow is something we should seriously consider.
>>>>>> 
>>>>>> I find cherry picking from branch to branch to be error prone in that
>>> it's
>>>>>> easy for someone to forget to cherry pick to all applicable branches
>>> and
>>>>>> you don't have any easy way to see the cherry picks are related.
>>>>>> 
>>>>>> When I worked at HP, we had automated tools check to see if you
>>> checked a
>>>>>> fix into a prior release, but not later releases. In such a situation,
>>> you
>>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
>>> longer
>>>>>> applicable in the later release(s), so you needed to mark it as
>>>>>> un-necessary (SVN supported this ability...not sure about Git).
>>>>>> 
>>>>>> 
>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Our current git workflow is confusing with the *forward branches and
>>>>>>> cherry-picking. Its hard to track on what all releases the commit has
>>>>>>> gone into unless I do some git log greping. Also, as a contributor, I
>>>>>>> endup creating patches for each branch as it doesn’t cleanly apply on
>>>>>>> different branches.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> I think we should have some guidelines. Here is what I propose.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 1.  There should be branch for every major release(ex: 4.3.x, 4.4.x,
>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on
>>>>>>> the respective branches.
>>>>>>> 2.  The branch naming convention is to be followed. Many branches
>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
>>>>>>> we have two physically distinct commits for the same change or fix and
>>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>>> 4.  There should always be a continous flow from release branches to
>>>>>>> master. This doesn’t mean cherry-picking. They should be merged(either
>>>>>>> ff or no-ff) which retains the commit ids and easily trackable with
>>>>>>> git branch --contains
>>>>>>>  *   Every bug fix should always flow from minimal release uptill
>>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>>  *   For ex. A bug 4.2.1 should be committed to
>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>  *   If someone forgets to do the merge, the next time a new commit
>>>>>> is
>>>>>>> done this will also get merged.
>>>>>>> 5.  There should always be a continuous flow from master to feature
>>>>>>> branches. Meaning all feature branch owners should proactively take
>>>>>>> any new commits from master by doing a merge from master
>>>>>>> 6.  The commits from feature branch will make to master on code
>>>>>>> complete through a merge.
>>>>>>> 7.  There should never be a merge from master to release branches
>>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>>>>>>> should have atleast bug id and correct author information
>>>>>>>  *   Cassandra's template: patch by <author>; reviewed by
>>> <committer>
>>>>>>> for CASSANDRA-<ticket>
>>>>>>> 9.  Once the release branch is created(after code freeze), any bug
>>>>>>> in jira can be marked with fix version current release(4.4) only on
>>>>>>> RM's approval and only they can go to the release branch.  This can be
>>>>>>> done through jira and with certain rules.(may be using jira vote?)
>>>>>>> this would save the cherry-picking time and another branch
>>> maintenance.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Ref:
>>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>> 
>>>>>>> ~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>*™*
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> *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: [DISCUSS][PROPOSAL] git workflow

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

There is also the problem of cherry-picking.
As a contributor, I always endup creating multiple patches for each branch as they don’t cleanly apply on the upward branches. which means distinct commits for each branch and I don’t easily know which all branches my commit exists unless I do grep.
if we follow merging strategy properly, apart from the first merge of the branch, everything else on top of it should be a painless merge. 



~Rajani



On 02-Jun-2014, at 10:51 pm, Marcus <sh...@gmail.com> wrote:

> I think many of the bullet points are what we are currently doing
> (guidelines for commit comments, feature branches need to stay in sync with
> master, no back-merging). I also think that much of what we do now is done
> the way it is simply because there *are* vast changes between versions.
> Classes are getting shuffled around and changed all the time. If its
> feasible to merge branch fixes to master, that's fine, but some quick tests
> seem to indicate that this will be messy getting started.
> 
> That leaves us with how we do releases. I'm fine with having single
> branches for major releases(4.3) and tagging the commits where each
> incremental release (4.3.x) is done. I'm trying to remember why we went
> with the -forward, I'm sure it's in the mailing list somewhere, but one of
> the nice things it provides is the ability for the release manager to
> control what changes are made during code freeze while giving people a
> place to stage fixes (though admittedly this is not always followed).
> Without -forward, would the flow be for each dev to have their own repo and
> issue pull requests for bugfixes?
> 
> 
> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <Ra...@citrix.com>
> wrote:
> 
>> Any other suggestions/objections/comments??
>> Can we discuss this in detail and agree to a process??
>> 
>> 
>> ~Rajani
>> 
>> 
>> 
>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <Ra...@citrix.com>
>> wrote:
>> 
>>> Yes as mike said, if its a one-off case we can do a empty merge(merge -s
>> ours) for it and git will assume its merged but will not bring in any
>> changes.
>>> 
>>> If the branches diverged a lot, for example after a major rewrite, we
>> could stop merging to that branch and above and make the fix manually.
>>> 
>>> 
>>> ~Rajani
>>> 
>>> 
>>> 
>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>>> 
>>>> Yep, that's what I was referring to in that a particular fix for an old
>>>> release may not apply to newer versions. That does happen.
>>>> 
>>>> We used to mark those as "don't need to merge to branch x" in SVN and
>> then
>>>> you handed it however made sense on the applicable branch(es).
>>>> 
>>>> 
>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>> Stephen.Turner@citrix.com>
>>>> wrote:
>>>> 
>>>>> What happens if a fix isn't relevant for newer versions, or has to be
>>>>> rewritten for newer versions because the code has changed? Don't the
>>>>> branches diverge and you end up cherry-picking after that?
>>>>> 
>>>>> --
>>>>> Stephen Turner
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>> Sent: 30 May 2014 18:48
>>>>> To: dev@cloudstack.apache.org
>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>> 
>>>>> I think this flow is something we should seriously consider.
>>>>> 
>>>>> I find cherry picking from branch to branch to be error prone in that
>> it's
>>>>> easy for someone to forget to cherry pick to all applicable branches
>> and
>>>>> you don't have any easy way to see the cherry picks are related.
>>>>> 
>>>>> When I worked at HP, we had automated tools check to see if you
>> checked a
>>>>> fix into a prior release, but not later releases. In such a situation,
>> you
>>>>> either 1) forgot to perform the check-in or 2) the check-in was no
>> longer
>>>>> applicable in the later release(s), so you needed to mark it as
>>>>> un-necessary (SVN supported this ability...not sure about Git).
>>>>> 
>>>>> 
>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Our current git workflow is confusing with the *forward branches and
>>>>>> cherry-picking. Its hard to track on what all releases the commit has
>>>>>> gone into unless I do some git log greping. Also, as a contributor, I
>>>>>> endup creating patches for each branch as it doesn’t cleanly apply on
>>>>>> different branches.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I think we should have some guidelines. Here is what I propose.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 1.  There should be branch for every major release(ex: 4.3.x, 4.4.x,
>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on
>>>>>> the respective branches.
>>>>>> 2.  The branch naming convention is to be followed. Many branches
>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
>>>>>> we have two physically distinct commits for the same change or fix and
>>>>>> is difficult to track unless you do cherry-pick -x
>>>>>> 4.  There should always be a continous flow from release branches to
>>>>>> master. This doesn’t mean cherry-picking. They should be merged(either
>>>>>> ff or no-ff) which retains the commit ids and easily trackable with
>>>>>> git branch --contains
>>>>>>   *   Every bug fix should always flow from minimal release uptill
>>>>>> master. A bug isnt fixed until the fix reaches master.
>>>>>>   *   For ex. A bug 4.2.1 should be committed to
>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>   *   If someone forgets to do the merge, the next time a new commit
>>>>> is
>>>>>> done this will also get merged.
>>>>>> 5.  There should always be a continuous flow from master to feature
>>>>>> branches. Meaning all feature branch owners should proactively take
>>>>>> any new commits from master by doing a merge from master
>>>>>> 6.  The commits from feature branch will make to master on code
>>>>>> complete through a merge.
>>>>>> 7.  There should never be a merge from master to release branches
>>>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>>>>>> should have atleast bug id and correct author information
>>>>>>   *   Cassandra's template: patch by <author>; reviewed by
>> <committer>
>>>>>> for CASSANDRA-<ticket>
>>>>>> 9.  Once the release branch is created(after code freeze), any bug
>>>>>> in jira can be marked with fix version current release(4.4) only on
>>>>>> RM's approval and only they can go to the release branch.  This can be
>>>>>> done through jira and with certain rules.(may be using jira vote?)
>>>>>> this would save the cherry-picking time and another branch
>> maintenance.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Please add your thoughts/suggestions/comments.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Ref:
>>>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>> 
>>>>>> ~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>*™*
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> *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: [DISCUSS][PROPOSAL] git workflow

[Marcus <sh...@gmail.com>]

I think many of the bullet points are what we are currently doing
(guidelines for commit comments, feature branches need to stay in sync with
master, no back-merging). I also think that much of what we do now is done
the way it is simply because there *are* vast changes between versions.
Classes are getting shuffled around and changed all the time. If its
feasible to merge branch fixes to master, that's fine, but some quick tests
seem to indicate that this will be messy getting started.

That leaves us with how we do releases. I'm fine with having single
branches for major releases(4.3) and tagging the commits where each
incremental release (4.3.x) is done. I'm trying to remember why we went
with the -forward, I'm sure it's in the mailing list somewhere, but one of
the nice things it provides is the ability for the release manager to
control what changes are made during code freeze while giving people a
place to stage fixes (though admittedly this is not always followed).
Without -forward, would the flow be for each dev to have their own repo and
issue pull requests for bugfixes?


On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <Ra...@citrix.com>
wrote:

> Any other suggestions/objections/comments??
> Can we discuss this in detail and agree to a process??
>
>
> ~Rajani
>
>
>
> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <Ra...@citrix.com>
> wrote:
>
> > Yes as mike said, if its a one-off case we can do a empty merge(merge -s
> ours) for it and git will assume its merged but will not bring in any
> changes.
> >
> > If the branches diverged a lot, for example after a major rewrite, we
> could stop merging to that branch and above and make the fix manually.
> >
> >
> > ~Rajani
> >
> >
> >
> > On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
> >
> >> Yep, that's what I was referring to in that a particular fix for an old
> >> release may not apply to newer versions. That does happen.
> >>
> >> We used to mark those as "don't need to merge to branch x" in SVN and
> then
> >> you handed it however made sense on the applicable branch(es).
> >>
> >>
> >> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> Stephen.Turner@citrix.com>
> >> wrote:
> >>
> >>> What happens if a fix isn't relevant for newer versions, or has to be
> >>> rewritten for newer versions because the code has changed? Don't the
> >>> branches diverge and you end up cherry-picking after that?
> >>>
> >>> --
> >>> Stephen Turner
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> >>> Sent: 30 May 2014 18:48
> >>> To: dev@cloudstack.apache.org
> >>> Subject: Re: [PROPOSAL] git workflow
> >>>
> >>> I think this flow is something we should seriously consider.
> >>>
> >>> I find cherry picking from branch to branch to be error prone in that
> it's
> >>> easy for someone to forget to cherry pick to all applicable branches
> and
> >>> you don't have any easy way to see the cherry picks are related.
> >>>
> >>> When I worked at HP, we had automated tools check to see if you
> checked a
> >>> fix into a prior release, but not later releases. In such a situation,
> you
> >>> either 1) forgot to perform the check-in or 2) the check-in was no
> longer
> >>> applicable in the later release(s), so you needed to mark it as
> >>> un-necessary (SVN supported this ability...not sure about Git).
> >>>
> >>>
> >>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>> Rajani.Karuturi@citrix.com> wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>>
> >>>>
> >>>> Our current git workflow is confusing with the *forward branches and
> >>>> cherry-picking. Its hard to track on what all releases the commit has
> >>>> gone into unless I do some git log greping. Also, as a contributor, I
> >>>> endup creating patches for each branch as it doesn’t cleanly apply on
> >>>> different branches.
> >>>>
> >>>>
> >>>>
> >>>> I think we should have some guidelines. Here is what I propose.
> >>>>
> >>>>
> >>>>
> >>>> 1.  There should be branch for every major release(ex: 4.3.x, 4.4.x,
> >>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on
> >>>> the respective branches.
> >>>> 2.  The branch naming convention is to be followed. Many branches
> >>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
> >>>> we have two physically distinct commits for the same change or fix and
> >>>> is difficult to track unless you do cherry-pick -x
> >>>> 4.  There should always be a continous flow from release branches to
> >>>> master. This doesn’t mean cherry-picking. They should be merged(either
> >>>> ff or no-ff) which retains the commit ids and easily trackable with
> >>>> git branch --contains
> >>>>    *   Every bug fix should always flow from minimal release uptill
> >>>> master. A bug isnt fixed until the fix reaches master.
> >>>>    *   For ex. A bug 4.2.1 should be committed to
> >>>> 4.2.x->4.3.x->4.4.x->master
> >>>>    *   If someone forgets to do the merge, the next time a new commit
> >>> is
> >>>> done this will also get merged.
> >>>> 5.  There should always be a continuous flow from master to feature
> >>>> branches. Meaning all feature branch owners should proactively take
> >>>> any new commits from master by doing a merge from master
> >>>> 6.  The commits from feature branch will make to master on code
> >>>> complete through a merge.
> >>>> 7.  There should never be a merge from master to release branches
> >>>> 8.  Every commit in LTS branch(targetted to any minor release)
> >>>> should have atleast bug id and correct author information
> >>>>    *   Cassandra's template: patch by <author>; reviewed by
> <committer>
> >>>> for CASSANDRA-<ticket>
> >>>> 9.  Once the release branch is created(after code freeze), any bug
> >>>> in jira can be marked with fix version current release(4.4) only on
> >>>> RM's approval and only they can go to the release branch.  This can be
> >>>> done through jira and with certain rules.(may be using jira vote?)
> >>>> this would save the cherry-picking time and another branch
> maintenance.
> >>>>
> >>>>
> >>>>
> >>>> Please add your thoughts/suggestions/comments.
> >>>>
> >>>>
> >>>>
> >>>> Ref:
> >>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>
> >>>> ~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>*™*
> >>>
> >>
> >>
> >>
> >> --
> >> *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: [DISCUSS][PROPOSAL] git workflow

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

Any other suggestions/objections/comments??
Can we discuss this in detail and agree to a process??


~Rajani



On 02-Jun-2014, at 9:32 am, Rajani Karuturi <Ra...@citrix.com> wrote:

> Yes as mike said, if its a one-off case we can do a empty merge(merge -s ours) for it and git will assume its merged but will not bring in any changes.
> 
> If the branches diverged a lot, for example after a major rewrite, we could stop merging to that branch and above and make the fix manually.
> 
> 
> ~Rajani
> 
> 
> 
> On 30-May-2014, at 11:26 pm, Mike Tutkowski <mi...@solidfire.com> wrote:
> 
>> Yep, that's what I was referring to in that a particular fix for an old
>> release may not apply to newer versions. That does happen.
>> 
>> We used to mark those as "don't need to merge to branch x" in SVN and then
>> you handed it however made sense on the applicable branch(es).
>> 
>> 
>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <St...@citrix.com>
>> wrote:
>> 
>>> What happens if a fix isn't relevant for newer versions, or has to be
>>> rewritten for newer versions because the code has changed? Don't the
>>> branches diverge and you end up cherry-picking after that?
>>> 
>>> --
>>> Stephen Turner
>>> 
>>> 
>>> -----Original Message-----
>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>> Sent: 30 May 2014 18:48
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [PROPOSAL] git workflow
>>> 
>>> I think this flow is something we should seriously consider.
>>> 
>>> I find cherry picking from branch to branch to be error prone in that it's
>>> easy for someone to forget to cherry pick to all applicable branches and
>>> you don't have any easy way to see the cherry picks are related.
>>> 
>>> When I worked at HP, we had automated tools check to see if you checked a
>>> fix into a prior release, but not later releases. In such a situation, you
>>> either 1) forgot to perform the check-in or 2) the check-in was no longer
>>> applicable in the later release(s), so you needed to mark it as
>>> un-necessary (SVN supported this ability...not sure about Git).
>>> 
>>> 
>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>>> Rajani.Karuturi@citrix.com> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> 
>>>> 
>>>> Our current git workflow is confusing with the *forward branches and
>>>> cherry-picking. Its hard to track on what all releases the commit has
>>>> gone into unless I do some git log greping. Also, as a contributor, I
>>>> endup creating patches for each branch as it doesn’t cleanly apply on
>>>> different branches.
>>>> 
>>>> 
>>>> 
>>>> I think we should have some guidelines. Here is what I propose.
>>>> 
>>>> 
>>>> 
>>>> 1.  There should be branch for every major release(ex: 4.3.x, 4.4.x,
>>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on
>>>> the respective branches.
>>>> 2.  The branch naming convention is to be followed. Many branches
>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>> 3.  Cherry-picking should be avoided. In git, when we cherry-pick,
>>>> we have two physically distinct commits for the same change or fix and
>>>> is difficult to track unless you do cherry-pick -x
>>>> 4.  There should always be a continous flow from release branches to
>>>> master. This doesn’t mean cherry-picking. They should be merged(either
>>>> ff or no-ff) which retains the commit ids and easily trackable with
>>>> git branch --contains
>>>>    *   Every bug fix should always flow from minimal release uptill
>>>> master. A bug isnt fixed until the fix reaches master.
>>>>    *   For ex. A bug 4.2.1 should be committed to
>>>> 4.2.x->4.3.x->4.4.x->master
>>>>    *   If someone forgets to do the merge, the next time a new commit
>>> is
>>>> done this will also get merged.
>>>> 5.  There should always be a continuous flow from master to feature
>>>> branches. Meaning all feature branch owners should proactively take
>>>> any new commits from master by doing a merge from master
>>>> 6.  The commits from feature branch will make to master on code
>>>> complete through a merge.
>>>> 7.  There should never be a merge from master to release branches
>>>> 8.  Every commit in LTS branch(targetted to any minor release)
>>>> should have atleast bug id and correct author information
>>>>    *   Cassandra's template: patch by <author>; reviewed by <committer>
>>>> for CASSANDRA-<ticket>
>>>> 9.  Once the release branch is created(after code freeze), any bug
>>>> in jira can be marked with fix version current release(4.4) only on
>>>> RM's approval and only they can go to the release branch.  This can be
>>>> done through jira and with certain rules.(may be using jira vote?)
>>>> this would save the cherry-picking time and another branch maintenance.
>>>> 
>>>> 
>>>> 
>>>> Please add your thoughts/suggestions/comments.
>>>> 
>>>> 
>>>> 
>>>> Ref:
>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>> 
>>>> ~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>*™*
>>> 
>> 
>> 
>> 
>> -- 
>> *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: [PROPOSAL] git workflow

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

Yes as mike said, if its a one-off case we can do a empty merge(merge -s ours) for it and git will assume its merged but will not bring in any changes.

If the branches diverged a lot, for example after a major rewrite, we could stop merging to that branch and above and make the fix manually.


~Rajani



On 30-May-2014, at 11:26 pm, Mike Tutkowski <mi...@solidfire.com> wrote:

> Yep, that's what I was referring to in that a particular fix for an old
> release may not apply to newer versions. That does happen.
> 
> We used to mark those as "don't need to merge to branch x" in SVN and then
> you handed it however made sense on the applicable branch(es).
> 
> 
> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <St...@citrix.com>
> wrote:
> 
>> What happens if a fix isn't relevant for newer versions, or has to be
>> rewritten for newer versions because the code has changed? Don't the
>> branches diverge and you end up cherry-picking after that?
>> 
>> --
>> Stephen Turner
>> 
>> 
>> -----Original Message-----
>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>> Sent: 30 May 2014 18:48
>> To: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSAL] git workflow
>> 
>> I think this flow is something we should seriously consider.
>> 
>> I find cherry picking from branch to branch to be error prone in that it's
>> easy for someone to forget to cherry pick to all applicable branches and
>> you don't have any easy way to see the cherry picks are related.
>> 
>> When I worked at HP, we had automated tools check to see if you checked a
>> fix into a prior release, but not later releases. In such a situation, you
>> either 1) forgot to perform the check-in or 2) the check-in was no longer
>> applicable in the later release(s), so you needed to mark it as
>> un-necessary (SVN supported this ability...not sure about Git).
>> 
>> 
>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
>> Rajani.Karuturi@citrix.com> wrote:
>> 
>>> Hi all,
>>> 
>>> 
>>> 
>>> Our current git workflow is confusing with the *forward branches and
>>> cherry-picking. Its hard to track on what all releases the commit has
>>> gone into unless I do some git log greping. Also, as a contributor, I
>>> endup creating patches for each branch as it doesn’t cleanly apply on
>>> different branches.
>>> 
>>> 
>>> 
>>> I think we should have some guidelines. Here is what I propose.
>>> 
>>> 
>>> 
>>>  1.  There should be branch for every major release(ex: 4.3.x, 4.4.x,
>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on
>>> the respective branches.
>>>  2.  The branch naming convention is to be followed. Many branches
>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>  3.  Cherry-picking should be avoided. In git, when we cherry-pick,
>>> we have two physically distinct commits for the same change or fix and
>>> is difficult to track unless you do cherry-pick -x
>>>  4.  There should always be a continous flow from release branches to
>>> master. This doesn’t mean cherry-picking. They should be merged(either
>>> ff or no-ff) which retains the commit ids and easily trackable with
>>> git branch --contains
>>>     *   Every bug fix should always flow from minimal release uptill
>>> master. A bug isnt fixed until the fix reaches master.
>>>     *   For ex. A bug 4.2.1 should be committed to
>>> 4.2.x->4.3.x->4.4.x->master
>>>     *   If someone forgets to do the merge, the next time a new commit
>> is
>>> done this will also get merged.
>>>  5.  There should always be a continuous flow from master to feature
>>> branches. Meaning all feature branch owners should proactively take
>>> any new commits from master by doing a merge from master
>>>  6.  The commits from feature branch will make to master on code
>>> complete through a merge.
>>>  7.  There should never be a merge from master to release branches
>>>  8.  Every commit in LTS branch(targetted to any minor release)
>>> should have atleast bug id and correct author information
>>>     *   Cassandra's template: patch by <author>; reviewed by <committer>
>>> for CASSANDRA-<ticket>
>>>  9.  Once the release branch is created(after code freeze), any bug
>>> in jira can be marked with fix version current release(4.4) only on
>>> RM's approval and only they can go to the release branch.  This can be
>>> done through jira and with certain rules.(may be using jira vote?)
>>> this would save the cherry-picking time and another branch maintenance.
>>> 
>>> 
>>> 
>>> Please add your thoughts/suggestions/comments.
>>> 
>>> 
>>> 
>>> Ref:
>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>> 
>>> ~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>*™*
>> 
> 
> 
> 
> -- 
> *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: [PROPOSAL] git workflow

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

Yep, that's what I was referring to in that a particular fix for an old
release may not apply to newer versions. That does happen.

We used to mark those as "don't need to merge to branch x" in SVN and then
you handed it however made sense on the applicable branch(es).


On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <St...@citrix.com>
wrote:

> What happens if a fix isn't relevant for newer versions, or has to be
> rewritten for newer versions because the code has changed? Don't the
> branches diverge and you end up cherry-picking after that?
>
> --
> Stephen Turner
>
>
> -----Original Message-----
> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> Sent: 30 May 2014 18:48
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] git workflow
>
> I think this flow is something we should seriously consider.
>
> I find cherry picking from branch to branch to be error prone in that it's
> easy for someone to forget to cherry pick to all applicable branches and
> you don't have any easy way to see the cherry picks are related.
>
> When I worked at HP, we had automated tools check to see if you checked a
> fix into a prior release, but not later releases. In such a situation, you
> either 1) forgot to perform the check-in or 2) the check-in was no longer
> applicable in the later release(s), so you needed to mark it as
> un-necessary (SVN supported this ability...not sure about Git).
>
>
> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> Rajani.Karuturi@citrix.com> wrote:
>
> > Hi all,
> >
> >
> >
> > Our current git workflow is confusing with the *forward branches and
> > cherry-picking. Its hard to track on what all releases the commit has
> > gone into unless I do some git log greping. Also, as a contributor, I
> > endup creating patches for each branch as it doesn’t cleanly apply on
> > different branches.
> >
> >
> >
> > I think we should have some guidelines. Here is what I propose.
> >
> >
> >
> >   1.  There should be branch for every major release(ex: 4.3.x, 4.4.x,
> > 5.0.x,5.1.x) and the minor releases should be tagged accordingly on
> > the respective branches.
> >   2.  The branch naming convention is to be followed. Many branches
> > with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >   3.  Cherry-picking should be avoided. In git, when we cherry-pick,
> > we have two physically distinct commits for the same change or fix and
> > is difficult to track unless you do cherry-pick -x
> >   4.  There should always be a continous flow from release branches to
> > master. This doesn’t mean cherry-picking. They should be merged(either
> > ff or no-ff) which retains the commit ids and easily trackable with
> > git branch --contains
> >      *   Every bug fix should always flow from minimal release uptill
> > master. A bug isnt fixed until the fix reaches master.
> >      *   For ex. A bug 4.2.1 should be committed to
> > 4.2.x->4.3.x->4.4.x->master
> >      *   If someone forgets to do the merge, the next time a new commit
> is
> > done this will also get merged.
> >   5.  There should always be a continuous flow from master to feature
> > branches. Meaning all feature branch owners should proactively take
> > any new commits from master by doing a merge from master
> >   6.  The commits from feature branch will make to master on code
> > complete through a merge.
> >   7.  There should never be a merge from master to release branches
> >   8.  Every commit in LTS branch(targetted to any minor release)
> > should have atleast bug id and correct author information
> >      *   Cassandra's template: patch by <author>; reviewed by <committer>
> > for CASSANDRA-<ticket>
> >   9.  Once the release branch is created(after code freeze), any bug
> > in jira can be marked with fix version current release(4.4) only on
> > RM's approval and only they can go to the release branch.  This can be
> > done through jira and with certain rules.(may be using jira vote?)
> > this would save the cherry-picking time and another branch maintenance.
> >
> >
> >
> > Please add your thoughts/suggestions/comments.
> >
> >
> >
> > Ref:
> > http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> > https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >
> > ~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>*™*
>



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

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

What happens if a fix isn't relevant for newer versions, or has to be rewritten for newer versions because the code has changed? Don't the branches diverge and you end up cherry-picking after that?

-- 
Stephen Turner


-----Original Message-----
From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com] 
Sent: 30 May 2014 18:48
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] git workflow

I think this flow is something we should seriously consider.

I find cherry picking from branch to branch to be error prone in that it's easy for someone to forget to cherry pick to all applicable branches and you don't have any easy way to see the cherry picks are related.

When I worked at HP, we had automated tools check to see if you checked a fix into a prior release, but not later releases. In such a situation, you either 1) forgot to perform the check-in or 2) the check-in was no longer applicable in the later release(s), so you needed to mark it as un-necessary (SVN supported this ability...not sure about Git).


On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi < Rajani.Karuturi@citrix.com> wrote:

> Hi all,
>
>
>
> Our current git workflow is confusing with the *forward branches and 
> cherry-picking. Its hard to track on what all releases the commit has 
> gone into unless I do some git log greping. Also, as a contributor, I 
> endup creating patches for each branch as it doesn’t cleanly apply on 
> different branches.
>
>
>
> I think we should have some guidelines. Here is what I propose.
>
>
>
>   1.  There should be branch for every major release(ex: 4.3.x, 4.4.x,
> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on 
> the respective branches.
>   2.  The branch naming convention is to be followed. Many branches 
> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>   3.  Cherry-picking should be avoided. In git, when we cherry-pick, 
> we have two physically distinct commits for the same change or fix and 
> is difficult to track unless you do cherry-pick -x
>   4.  There should always be a continous flow from release branches to 
> master. This doesn’t mean cherry-picking. They should be merged(either 
> ff or no-ff) which retains the commit ids and easily trackable with 
> git branch --contains
>      *   Every bug fix should always flow from minimal release uptill
> master. A bug isnt fixed until the fix reaches master.
>      *   For ex. A bug 4.2.1 should be committed to
> 4.2.x->4.3.x->4.4.x->master
>      *   If someone forgets to do the merge, the next time a new commit is
> done this will also get merged.
>   5.  There should always be a continuous flow from master to feature 
> branches. Meaning all feature branch owners should proactively take 
> any new commits from master by doing a merge from master
>   6.  The commits from feature branch will make to master on code 
> complete through a merge.
>   7.  There should never be a merge from master to release branches
>   8.  Every commit in LTS branch(targetted to any minor release) 
> should have atleast bug id and correct author information
>      *   Cassandra's template: patch by <author>; reviewed by <committer>
> for CASSANDRA-<ticket>
>   9.  Once the release branch is created(after code freeze), any bug 
> in jira can be marked with fix version current release(4.4) only on 
> RM's approval and only they can go to the release branch.  This can be 
> done through jira and with certain rules.(may be using jira vote?) 
> this would save the cherry-picking time and another branch maintenance.
>
>
>
> Please add your thoughts/suggestions/comments.
>
>
>
> Ref:
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>
> ~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: [PROPOSAL] git workflow

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

I think this flow is something we should seriously consider.

I find cherry picking from branch to branch to be error prone in that it's
easy for someone to forget to cherry pick to all applicable branches and
you don't have any easy way to see the cherry picks are related.

When I worked at HP, we had automated tools check to see if you checked a
fix into a prior release, but not later releases. In such a situation, you
either 1) forgot to perform the check-in or 2) the check-in was no longer
applicable in the later release(s), so you needed to mark it as
un-necessary (SVN supported this ability...not sure about Git).


On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
Rajani.Karuturi@citrix.com> wrote:

> Hi all,
>
>
>
> Our current git workflow is confusing with the *forward branches and
> cherry-picking. Its hard to track on what all releases the commit has gone
> into unless I do some git log greping. Also, as a contributor, I endup
> creating patches for each branch as it doesn’t cleanly apply on different
> branches.
>
>
>
> I think we should have some guidelines. Here is what I propose.
>
>
>
>   1.  There should be branch for every major release(ex: 4.3.x, 4.4.x,
> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on the
> respective branches.
>   2.  The branch naming convention is to be followed. Many branches with
> 4.3, 4.3.0, 4.3.1 etc. is confusing
>   3.  Cherry-picking should be avoided. In git, when we cherry-pick, we
> have two physically distinct commits for the same change or fix and is
> difficult to track unless you do cherry-pick -x
>   4.  There should always be a continous flow from release branches to
> master. This doesn’t mean cherry-picking. They should be merged(either ff
> or no-ff) which retains the commit ids and easily trackable with git branch
> --contains
>      *   Every bug fix should always flow from minimal release uptill
> master. A bug isnt fixed until the fix reaches master.
>      *   For ex. A bug 4.2.1 should be committed to
> 4.2.x->4.3.x->4.4.x->master
>      *   If someone forgets to do the merge, the next time a new commit is
> done this will also get merged.
>   5.  There should always be a continuous flow from master to feature
> branches. Meaning all feature branch owners should proactively take any new
> commits from master by doing a merge from master
>   6.  The commits from feature branch will make to master on code complete
> through a merge.
>   7.  There should never be a merge from master to release branches
>   8.  Every commit in LTS branch(targetted to any minor release) should
> have atleast bug id and correct author information
>      *   Cassandra's template: patch by <author>; reviewed by <committer>
> for CASSANDRA-<ticket>
>   9.  Once the release branch is created(after code freeze), any bug in
> jira can be marked with fix version current release(4.4) only on RM's
> approval and only they can go to the release branch.  This can be done
> through jira and with certain rules.(may be using jira vote?) this would
> save the cherry-picking time and another branch maintenance.
>
>
>
> Please add your thoughts/suggestions/comments.
>
>
>
> Ref:
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>
> ~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>*™*