> -----Original Message-----
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Friday, August 01, 2014 7:42 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] git workflow
>
>
> On Aug 1, 2014, at 10:30 AM, Nate Gordon <nate.gor...@appcore.com>
> wrote:
>
> > +1
> >
> > On CI, I think it should run on any branch that wants to maintain quality.
> > So master, develop, releases, hotfixes, and support. It would be
> > awesome if I could elect to have my random other branches run CI as
> > well, but my guess is that we would need more hardware to pull that
> > off. Hopefully I'll have some extra hardware to donate to the cause in
> > the next few months, but need to get everything currently on it moved
> somewhere else first.
> >
>
> FWIW, a few of us are looking at a TravisCI setup to run the simulator.
> Assuming the tests would run quickly (< 60 minutes on travis hardware),
> we could have tests run on every commit for every branch mirrored on
> github (.I hear some of you say "yeah right."). But imho that would be an
> ideal scenario, as folks own fork could also run the simulator automatically.
> Will see if we get anywhere with this.
>
[Animesh] that will be awesome
> >
> > On Fri, Aug 1, 2014 at 5:37 AM, Rohit Yadav
> > <rohit.ya...@shapeblue.com>
> > wrote:
> >
> >>
> >> On 01-Aug-2014, at 1:40 am, Alena Prokharchyk <
> >> alena.prokharc...@citrix.com> wrote:
> >>
> >>> 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
> >>
> >> Automated systems will be there for main branches such as develop,
> >> master, release etc.
> >>
> >> The frequency would vary, the best I'm able to get on my local lab is
> >> 50 mins per BVT run (advanced).
> >>
> >> For feature, bug fix, developer's personal branches developers can
> >> setup a CI with Travis, Azure (Edison says free subscription is
> >> available), AWS
> >> (free-tier) etc. at least say once a day run the BVTs on their
> >> laptop/desktop before pushing the code to their remote branch.
> >>
> >>>
> >>> 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?
> >>
> >> I think a human should do it.
> >> In the past we've seen developer revert breaking commit(s) and
> >> reaching out to the author/community about it.
> >>
> >> Regards.
> >>
> >>>
> >>>
> >>> -Alena.
> >>>
> >>> On 7/31/14, 4:28 PM, "Rohit Yadav" <rohit.ya...@shapeblue.com>
> wrote:
> >>>
> >>>> Comments in-line;
> >>>>
> >>>> On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk
> >>>> <alena.prokharc...@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.ya...@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.
> >>
> >> Regards,
> >> Rohit Yadav
> >> Software Architect, ShapeBlue
> >> M. +41 779015219 | rohit.ya...@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.
> >>
> >
> >
> >
> > --
> >
> >
> > *Nate Gordon*Director of Technology | Appcore - the business of cloud
> > computing®
> >
> > Office +1.800.735.7104 | Direct +1.515.612.7787
> > nate.gor...@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.
