On Jul 31, 2014, at 4:46 AM, Rajani Karuturi <rajani.karut...@citrix.com> 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: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git 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 <daan.hoogl...@gmail.com> 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 >> <rajani.karut...@citrix.com> wrote: >>> For the git flow: >>> 1. We agreed to follow git-flow explained here >>> http://nvie.com/posts/a-successful-git-branching-model/ >>> 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. http://stackoverflow.com/a/16866118/201514 >>> >>> using the git-flow git extension available at >>> https://github.com/nvie/gitflow 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 >>> (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator<https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes,+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 >
