cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajani Karuturi <>
Subject Re: [Summary] checkin process
Date Thu, 31 Jul 2014 08:46:58 GMT
to start using git-flow from 4.5+, we need to have the latest stable version which can be master
and I assumed that would be 4.4
point 2. should be modified assuming no previous releases
>> 2a. branch ‘develop’ from 'master’
>> 2b. branch ‘release/4.5' from the develop
>> 2c. merge ‘release/4.5' to master once the release voting is done.

Are we waiting for Leo to put up a proposal? 


On 31-Jul-2014, at 1:09 pm, Daan Hoogland <> wrote:

> I answerred this from my phone but it did't get through so here my
> comment again:
> We can't cut a new master from 4.4 without enormous work. I spend two
> days on getting 4.4 in line with 4.4-forward and as Leo has shown the
> work for getting all features from master into master will be much
> greater. So the proposal should be that we maintain 4.4 as traditional
> and start this work flow from 4.5+
> As for the additions you gave; these are reviewer guidelines for my
> part not requirements to a work flow.
> In general I am +1 on putting this to vote.
> On Thu, Jul 31, 2014 at 6:22 AM, Rajani Karuturi
> <> wrote:
>> For the git flow:
>> 1. We agreed to follow git-flow explained here
>> 2. This is the proposal for first cut
>> 2a. rename 'master' to 'develop’
>> 2b. branch a new 'master' from ‘4.4’ and update tags with release/4.4.0
>> 2c. branch ‘release/4.5' from the develop
>> 2d. merge ‘release/4.5' to master once the release voting is done.
>> 3. This would be the flow for a hot fix
>> 3a. branch off from the release tag on master. in this case it would be release/4.4.0
>> 3b. commit the fixes in hotfix/4.4.1
>> 3c. do the release
>> 3d. merge to develop
>> 3e. merge to master and update tags
>> 3f. delete hot fix branch
>> 4. for any LTS release create a support branch when required using git-flow support
>> 4a.
>> using the git-flow git extension available at can
reduce the number of commands/errors
>> In addition:
>> 1. Every commit should have unit tests
>> 2. every feature/merge request should have unit and marvin integration tests
>> 3. A commit should not have check style or find bugs issues
>> 4. any coverity issues reported in the new code should be addressed immediately
>> 5. every developer should run the BVT on the simulator before doing a checkin (<,+using+Simulator>)
>> (This I am not very sure. May be we should let jenkins handle it and report integration
failures if any?)
>> Please add/amend if I missed anything.
>> Can we call for a vote on this and freeze this without further delay?
>> ~Rajani
> -- 
> Daan

View raw message