cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: [VOTE] git workflow
Date Wed, 06 Aug 2014 14:10:51 GMT
On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav <> wrote:
> Hi,
> Comments in-line;
> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk <> 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 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 ->

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.


View raw message