cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <>
Subject Re: [Summary] checkin process
Date Thu, 31 Jul 2014 09:17:01 GMT

On Jul 31, 2014, at 4:46 AM, Rajani Karuturi <> wrote:

> 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? 

Anyone really :)

Someone mentioned:

You could add a section on 'gitflow' and basically dump your bullet list.

Then we can edit it and call a vote .

> ~Rajani
> 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
>>> (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