To me this pretty much ties in to the discussion about the simulator and the BVT/CI suite. This works very neatly with the work Alex has been doing and his proposal on how to deal with the BVT test suite.
His original proposal was about constantly checking master and reverting any commits that would cause master to break. If we would adopt another branching model like git flow we can change this around to, merge only when all checks are green. Given an community that cares about the quality of the software that they are releasing it will help having a more stable develop/master branch. The big idea is that we get small chunks that we can test individually from each other and once verified merge them into the various branches where we need them. Master would be a special case where only the release manager merges the individual branches that are going to be part of a release. If i got everything correctly (which i doubt, so please correct me). X develops feature F1 Y develops feature F2 Z develops bugfix B1 They are all tested individually and after green light merged into develop, so developers can work with the latest greatest. On release time we can all decide to take F1 and B1 into the release because they are release grade, so they get merged into master. At all times we can track what is where because of the merging the git commit ids will be the same so a simple check on which branches contain a commit id will tell you where a certain feature or bug fix is included. It requires discipline and a trustworthily CI system, but with those things in place it’s pretty sweet. We run other projects with a similar branching scheme and it works really well. It’s worth to keep pointing out that this is not a standalone thing, it should be regarded with the context of a CI system (or committers doing reviews) that can actually tell us if CloudStack works . Cheers, Hugo On 6 aug. 2014, at 16:10, David Nalley <da...@gnsa.us> wrote: > On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: >> >> Hi, >> >> Comments in-line; >> >> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk >> <alena.prokharc...@citrix.com> wrote: >> >>> Rayees, >>> >>> I think you have the same misunderstanding as a lot of other folks >>> (including myself) had in the beginning - seeing develop branch as a trunk >>> branch that gets merged into master on a regular basis after the BVT/CI >>> tests pass. So the master branch reflects the develop branch minus changes >>> that didn¹t pass the tests and weren¹t merged into master - lets refer to >>> it as implementation #1 >>> >>> That¹s not what git workflow/this thread proposes. In git workflow master >>> branch reflects the latest stable release instead. So for example, we >>> released 4.4, and that what you would see the master to be as we merge the >>> *release branch to master, not the *develop to master. And develop branch >>> becomes the trunk branch where all the new fixes go to. I would look at >>> the master as at the stable branch, where you can track the history for >>> all the major releases as for each of them the master branch has >>> corresponding tags - lets call it implementation #2 >>> >>> I still don¹t see many advantages in implementation #2 - making the master >>> build stable by simply making it reflect the latest release branch. >>> Because you: >>> >>> * never cut the release from master branch >> >> We’ve a stable branch that gets rolling/continuous releases which is good. >> >>> * if you are the customer, and need the latest stable code, you download >>> the official RPM >>> * if you are a developer, you always want to download the latest code, and >>> that comes from *develop branch >>> * if you want to look at the latest stable release, you look at the >>> release branch as per CS git workflow implementation we never remove the >>> release branches (they are needed for maintenance releases) >> >> IMO We “should" remove the release branches when done. Instead there is a >> support workflow with git-flow (see support >> http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git >> flow support etc. though experimental). >> > > You aren't aiding your case by suggesting that we use experimental tooling. > > So removing a release branch worries me. Will there be loss of commit > information? I know that heretofore, each release has contained > commits that aren't in master. Whether that's good, bad or > indifferent, that is the fact, and I personally think that is unlikely > to change in the short term. > > Or put more succinctly, what does removing a release branch buy us? > > So I like most of the things about this proposal - I like doing all > the work in the feature/bug branches. But the rest of this workflow > befuddles me a bit. I don't think that the workflow will result in a > stable 'master' or that we are really doing anything significant by > pushing what is master now to become the develop branch. In the page > describing this, pushes to the develop branch seem welcome 'when a > feature is completed' - so develop will be as messy as master is > today, frequently broken, and no improvement in quality. This attempts > to solve a quality problem with workflow, and I don't think it can do > that. Instead, we end up with develop being cluttered and as messy as > current master, and we spend time trying to get merge commits from > develop -> master and hoping things don't diverge so far in our > release branches that we can merge fixes from develop -> master -> > release-branches. > > This is a bit of a change from what we are doing now; why are we doing > it? A stable master? I am not sure how a workflow change enforces a > stable master. Improved quality? A workflow change might be a part of > the solution, but there seems to be missing something that enforces > quality or gates on working functionality. > > --David
