cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajani Karuturi <>
Subject [PROPOSAL] git workflow
Date Fri, 30 May 2014 16:49:46 GMT
Hi all,

Our current git workflow is confusing with the *forward branches and cherry-picking. Its hard
to track on what all releases the commit has gone into unless I do some git log greping. Also,
as a contributor, I endup creating patches for each branch as it doesn’t cleanly apply on
different branches.

I think we should have some guidelines. Here is what I propose.

  1.  There should be branch for every major release(ex: 4.3.x, 4.4.x, 5.0.x,5.1.x) and the
minor releases should be tagged accordingly on the respective branches.
  2.  The branch naming convention is to be followed. Many branches with 4.3, 4.3.0, 4.3.1
etc. is confusing
  3.  Cherry-picking should be avoided. In git, when we cherry-pick, we have two physically
distinct commits for the same change or fix and is difficult to track unless you do cherry-pick
  4.  There should always be a continous flow from release branches to master. This doesn’t
mean cherry-picking. They should be merged(either ff or no-ff) which retains the commit ids
and easily trackable with git branch --contains
     *   Every bug fix should always flow from minimal release uptill master. A bug isnt fixed
until the fix reaches master.
     *   For ex. A bug 4.2.1 should be committed to 4.2.x->4.3.x->4.4.x->master
     *   If someone forgets to do the merge, the next time a new commit is done this will
also get merged.
  5.  There should always be a continuous flow from master to feature branches. Meaning all
feature branch owners should proactively take any new commits from master by doing a merge
from master
  6.  The commits from feature branch will make to master on code complete through a merge.
  7.  There should never be a merge from master to release branches
  8.  Every commit in LTS branch(targetted to any minor release) should have atleast bug id
and correct author information
     *   Cassandra's template: patch by <author>; reviewed by <committer> for
  9.  Once the release branch is created(after code freeze), any bug in jira can be marked
with fix version current release(4.4) only on RM's approval and only they can go to the release
branch.  This can be done through jira and with certain rules.(may be using jira vote?) this
would save the cherry-picking time and another branch maintenance.

Please add your thoughts/suggestions/comments.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message