cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <>
Subject Re: [VOTE] git workflow
Date Thu, 31 Jul 2014 23:40:05 GMT
Thank you, Rohit. Couple more things we have to clarify in the wiki. The
doc says "Developer should run the BVT on the simulator before doing a
checkin², but it doesn¹t mention anything about the CI. So here are my
1) CI execution

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

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


On 7/31/14, 4:28 PM, "Rohit Yadav" <> wrote:

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