Return-Path: 
 <dev-return-62306-apmail-cloudstack-dev-archive=cloudstack.apache.org@cloudstack.apache.org>
X-Original-To: apmail-cloudstack-dev-archive@www.apache.org
Delivered-To: apmail-cloudstack-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id A692B114C7
	for <apmail-cloudstack-dev-archive@www.apache.org>;
 Wed,  6 Aug 2014 14:53:29 +0000 (UTC)
Received: (qmail 45113 invoked by uid 500); 6 Aug 2014 14:53:29 -0000
Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org
Received: (qmail 45064 invoked by uid 500); 6 Aug 2014 14:53:29 -0000
Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cloudstack.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cloudstack.apache.org>
List-Post: <mailto:dev@cloudstack.apache.org>
List-Id: <dev.cloudstack.apache.org>
Reply-To: dev@cloudstack.apache.org
Delivered-To: mailing list dev@cloudstack.apache.org
Received: (qmail 45051 invoked by uid 99); 6 Aug 2014 14:53:28 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Aug 2014 14:53:28 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of trippie@gmail.com designates
 74.125.82.180 as permitted sender)
Received: from [74.125.82.180] (HELO mail-we0-f180.google.com) (74.125.82.180)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Aug 2014 14:53:24 +0000
Received: by mail-we0-f180.google.com with SMTP id w61so2763723wes.39
        for <dev@cloudstack.apache.org>; Wed, 06 Aug 2014 07:53:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=sender:from:content-type:mime-version:subject:in-reply-to:date:cc
         :message-id:references:to;
        bh=lXtVgvJ8edVQzpz9EgtrMzdq4C9I4eLIAJg2yX719lI=;
        b=GWeAsBPEBcoz42+iWAX2bFfN34y5PCqgobImLnsfTbqcTMjswwJSBzGETrGpdZEE2D
         vUDCyHMWQJuFejUtcO4/3NwaaeEih+dZIEYHu/tP4Lpbd20WVCvquuaJq/JAE2/2LdM0
         /s6osiGOlQK+Hq97BvSfhqruN+aS0bHXWlvMvacLf2qZ+zd1C5L97tFWKWCicn6PiKC8
         0eDnUs8kGVFZGmkLCMgEZciSmqfBtbJyUWuZcthUQkPvLMKjDAzzIKyxDEzz+JoM0EwZ
         pdG1a1wwOXVr7Qt7ny1sh2SV0a85XeDTqbUtHQX59NaDV8r+Wg1bzMk/Mq0PylpWxaQh
         sZ/Q==
X-Received: by 10.180.10.98 with SMTP id h2mr17014231wib.29.1407336783273;
        Wed, 06 Aug 2014 07:53:03 -0700 (PDT)
Received: from [192.168.168.105] (53532F3A.cm-6-4a.dynamic.ziggo.nl.
 [83.83.47.58])
        by mx.google.com with ESMTPSA id
 au7sm2984789wjc.41.2014.08.06.07.53.01
        for <multiple recipients>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Wed, 06 Aug 2014 07:53:01 -0700 (PDT)
Sender: Trippie <trippie@gmail.com>
From: Hugo Trippaers <hugo@trippaers.nl>
X-Google-Original-From: Hugo Trippaers <trippie@GMAIL.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_C2F11075-DA4A-461C-A627-18A2AC74212A"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [VOTE] git workflow
In-Reply-To: 
 <CAKprHVYXMrZ=3ybMSLvfJvVmrMq5nie_ahijYuK44V66amWanQ@mail.gmail.com>
Date: Wed, 6 Aug 2014 16:53:05 +0200
Cc: Alena Prokharchyk <Alena.Prokharchyk@citrix.com>
Message-Id: <E885139D-0D7A-4B38-8763-9C6D04F63C5D@GMAIL.com>
References: <20140731102839.A1876816018@nike.apache.org>
 <C3637609BC1C0D40A2AC70F4760C7A2D8EF8AE@SJCPEX01CL02.citrite.net>
 <D0066FC9.5FAC1%min.chen@citrix.com>
 <4EFCA102B2C89A43BD3D0B497BFB87841607EFDE@SJCPEX01CL01.citrite.net>
 <75942ED3FD12D64EABE71209BD0F62CC724EC7@SJCPEX01CL02.citrite.net>
 <79D6DD2D292A984AA8CE38C4DB1C8CD4848E57@SJCPEX01CL02.citrite.net>
 <D0068D77.4B634%alena.prokharchyk@citrix.com>
 <9CE93363-636B-4712-894B-C3F39184924C@shapeblue.com>
 <CAKprHVYXMrZ=3ybMSLvfJvVmrMq5nie_ahijYuK44V66amWanQ@mail.gmail.com>
To: dev@cloudstack.apache.org
X-Mailer: Apple Mail (2.1878.6)
X-Virus-Checked: Checked by ClamAV on apache.org

--Apple-Mail=_C2F11075-DA4A-461C-A627-18A2AC74212A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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=92s pretty sweet. We run other projects with a =
similar branching scheme and it works really well. It=92s 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 <david@gnsa.us> wrote:

> On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav =
<rohit.yadav@shapeblue.com> wrote:
>>=20
>> Hi,
>>=20
>> Comments in-line;
>>=20
>> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk =
<Alena.Prokharchyk@citrix.com> wrote:
>>=20
>>> Rayees,
>>>=20
>>> 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=B9t pass the tests and weren=B9t merged into master -  =
lets refer to
>>> it as implementation #1
>>>=20
>>> That=B9s 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
>>>=20
>>> I still don=B9t see many advantages in implementation #2 - making =
the master
>>> build stable by simply making it reflect the latest release branch.
>>> Because you:
>>>=20
>>> * never cut the release from master branch
>>=20
>> We=92ve a stable branch that gets rolling/continuous releases which =
is good.
>>=20
>>> * 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)
>>=20
>> IMO We =93should" 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).
>>=20
>=20
> You aren't aiding your case by suggesting that we use experimental =
tooling.
>=20
> 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.
>=20
> Or put more succinctly, what does removing a release branch buy us?
>=20
> 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.
>=20
> 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.
>=20
> --David


--Apple-Mail=_C2F11075-DA4A-461C-A627-18A2AC74212A--