cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <Alena.Prokharc...@citrix.com>
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
questions:
 
1) CI execution

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

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


-Alena.

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

>Comments in-line;
>
>On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk
><Alena.Prokharchyk@citrix.com> wrote:
>
>> Done, updated the wiki page with my comments. Copy/pasting here:
>>
>> Open items:
>> 1) Which bugs can be submitted to develop branch directly.
>> Document http://nvie.com/posts/a-successful-git-branching-model/
>>mentions
>> that the
>> *hotfix branch should be created for the blocker/critical bugs in the
>> current production release. What about bugs happenning in the
>>*release(the
>> one that hasn't been released yet)/*develop
>> branches ? Should we fix them directly in those branches, or should we
>> branch out off the *release
>> branch, fix the problem, and merge the fix to *release?
>
>As per nvie;
>
>once cut out release branches should only have bugfixes. So, bugfixes can
>directly land on release branch and then cherry-picked or merge to the
>develop branch.
>
>For bugs on develop branch, the commits can land directly on the develop
>branch or can be worked in a branch checked out from develop and when
>done merged back.
>
>In my opinion, for any case developers should not work on any of the
>branches (master, release, develop) directly but checkout branch and work
>on it and merge back (or cherry-pick or squash merge) to respective
>branch only when their work is complete, with unit tests and validated
>using unit testing and smoke tests (BVT).
>
>> We should decide:
>> for which bugs the hot fix branch should be cut, and which fixes can go
>> directly to *develop/*release branches. This criteria has to be defined
>>in
>> the doc, and be based on the a) bug severity b) number of people who
>>work
>> on the bug - if more than one, then we cut the new branch c)
>> feedback/review is needed for the bug d) anything else?
>
>What you suggest is fine. I think couple of areas which can qualify for
>bugfixes (hotfixes) would be related to security, database changes,
>systemvms, agent, hypervisor, network, storage, anything that could be
>considered a blocker.
>
>I¹m not sure but I think adopting nvie could possibly affect our release
>process, I would let PMC and experienced RMs to comment on this issue and
>if they would like any modifications to the release process?
>
>On twitter I asked @nvie if he would have any change in the nvie model,
>he has a short reply:
>https://twitter.com/nvie/status/494870892917563393
>
>Regards,
>Rohit Yadav
>Software Architect, ShapeBlue
>M. +41 779015219 | rohit.yadav@shapeblue.com
>Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
>
>Find out more about ShapeBlue and our range of CloudStack related services
>
>IaaS Cloud Design &
>Build<http://shapeblue.com/iaas-cloud-design-and-build//>
>CSForge ­ rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>CloudStack Infrastructure
>Support<http://shapeblue.com/cloudstack-infrastructure-support/>
>CloudStack Bootcamp Training
>Courses<http://shapeblue.com/cloudstack-training/>
>
>This email and any attachments to it may be confidential and are intended
>solely for the use of the individual to whom it is addressed. Any views
>or opinions expressed are solely those of the author and do not
>necessarily represent those of Shape Blue Ltd or related companies. If
>you are not the intended recipient of this email, you must neither take
>any action based upon its contents, nor copy or show it to anyone. Please
>contact the sender if you believe you have received this email in error.
>Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>Services India LLP is a company incorporated in India and is operated
>under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
>a company incorporated in Brasil and is operated under license from Shape
>Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
>South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
>is a registered trademark.


Mime
View raw message