cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject Re: [VOTE] git workflow
Date Tue, 05 Aug 2014 20:59:41 GMT

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

TL;DR? I hear you and the wiki is changing a lot, so just go through the cheatsheet and come
back to this email:

If you need a quick intro, see this 6 min video:

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

Using git-flow to releave your headaches:
What is git-flow:

Or, better install git-flow and play with it on a sample repo:
Play with it —

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

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

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

IMHO we can beat any workflow so it can only work if everyone agree and follows the workflow
and other good stuff from the Git wiki:

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

On 05-Aug-2014, at 8:51 pm, Prachi Damle <> wrote:

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

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

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

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

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

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

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

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

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

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


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

Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 |
Blog: | Twitter: @_bhaisaab

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

IaaS Cloud Design & Build<>
CSForge – rapid IaaS deployment framework<>
CloudStack Consulting<>
CloudStack Infrastructure Support<>
CloudStack Bootcamp Training Courses<>

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.

View raw message