cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <>
Subject RE: [VOTE] Adapting git workflow for release branches
Date Mon, 18 Aug 2014 19:04:14 GMT

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

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

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

View raw message