Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of daan.hoogland@gmail.com
 designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D007D650.4B803%alena.prokharchyk@citrix.com>
References: <20140731102839.A1876816018@nike.apache.org>
 <C3637609BC1C0D40A2AC70F4760C7A2D8EF8AE@SJCPEX01CL02.citrite.net>
 <D0066FC9.5FAC1%min.chen@citrix.com>
 <4EFCA102B2C89A43BD3D0B497BFB87841607EFDE@SJCPEX01CL01.citrite.net>
 <5A68D8ED-F3BB-4716-A1A4-FFFA8EFFC9DE@gmail.com>
 <75942ED3FD12D64EABE71209BD0F62CC72505F@SJCPEX01CL02.citrite.net>
 <CAP997UeP-mFua6+3QAH7ZRzL74w1_eQQt5fdwWTLfhOZ-XO-1Q@mail.gmail.com>
 <CAKprHVbqa1OFYLHavPdVqPUM4E5T9=f4XSQ42-WYzPXWZnLfXw@mail.gmail.com>
 <CAGQtxvYUCZ9-LMrDgQi_gF1LxAzd4FtG5HjG9+WsBOEnAYnsfg@mail.gmail.com>
 <51ACB359-5F26-4AE1-B1BB-E0B7B0EE5422@citrix.com>
 <CAGQtxvZSMt2-bQqVLV44jSDMg3uCLCJkNMOrj2RBimzYX+ku-w@mail.gmail.com>
 <D007AA8E.4B731%alena.prokharchyk@citrix.com>
 <ED0E6F17-C248-4275-B900-8F6201A2704E@shapeblue.com>
 <D007B28E.4B762%alena.prokharchyk@citrix.com>
 <252B3524-FFE0-4111-9238-E08095C85492@shapeblue.com>
 <CAKprHVbB6FqhYCWwDyHvpcE=yThp7gsdS9mEsvWjBoQ8Huc9qA@mail.gmail.com>
 <D007C1AD.4B7A5%alena.prokharchyk@citrix.com>
 <9BA1B9D2-33D9-438A-8D85-F1659D5269C6@shapeblue.com>
 <D007CC5B.4B7DE%alena.prokharchyk@citrix.com>
 <CAP997UcDb56P5NtjKJfuhnaV0vum5AkXnmST9CgdFO9fFqE+3g@mail.gmail.com>
 <D007D650.4B803%alena.prokharchyk@citrix.com>
From: Daan Hoogland <daan.hoogland@gmail.com>
Date: Wed, 6 Aug 2014 22:59:52 +0200
Message-ID: 
 <CAGQtxvb196jeBP7yegYHvCQnOB1CT9N9-yiQDvc9wkdLKEKb0Q@mail.gmail.com>
Subject: Re: [VOTE] git workflow
To: dev <dev@cloudstack.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Alena,

I think this is a matter of semantics. If you call the latest version
that got through the CI a pre-release and add them as releases in the
git-flow way of working on master you've got what you envision.

In spite of my mail this morning I am not a warrior (though I like the
compliment, Rohit) of gitflow but I feel that it fits whatever we need
so far. I have read no contradiction to that so far. The only real
change to our present way of working , given that we will use support
branches, is that we don't build releases on the basis of cherry-picks
anymore, which is not a very big change. Other then that, naming is
all that is left.

Maybe I lost view on the obstacles and objections and am being short
sighted here, please advice,
Daan

On Wed, Aug 6, 2014 at 9:59 PM, Alena Prokharchyk
<Alena.Prokharchyk@citrix.com> wrote:
>
>
> On 8/6/14, 12:52 PM, "Erik Weber" <terbolous@gmail.com> wrote:
>
>>On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>>Alena.Prokharchyk@citrix.com> wrote:
>>
>>> Agree with you, Rohit. The changes to the git model we use, are needed
>>> indeed. But we should address only the problems that CS faces, and the
>>> main problem - quality control. The proposal should be limited just to
>>>the
>>> changes that are really needed for the CS, and that will work with the
>>> current CS model (minor maintenance releases support is a part of it)
>>>
>>>
>>
>>Theoretically you don't really have to change anything other than merging
>>instead of cherry picking.
>>That is the main issue from a release perspective.
>>
>>But I still think there are good reasons to do so;
>>
>>1) using a well known way of handling code/releases instantly tells new
>>contributors / committers how we work. add to the fact that there exists
>>tools to help doing this correctly is a bonus.
>>2) having a known stable (atleast in theory) release as master is good
>>practice. although not many users will be running from git, i still
>>consider it to be good practice.
>>3) there is a huge belief in this thread/discussion that as long as
>>something passes CI / BVT it is considered stable. The fact is that it is
>>not. Take the recent 4.4 release as a good example, where a new install
>>was
>>not working at all at the point of release. Now, this is more a CI / test
>>coverage issue than git workflow issue, but i find it weird to use as an
>>argument for not improving the workflow.
>>
>>--
>>Erik
>
> I=C2=B9m not arguing against keeping master release stable; I advocate fo=
r it.
> But we can=C2=B9t adopt git workflow way of keeping master branch to be a
> reflection of the latest release branch. It will not work with our way of
> handling maintenance releases for multiple versions of CS - see another
> thread.
>
> Instead, master branch should reflect the latest code that passed the CI
> test (the code merged from *develop after CI passes). The release branche=
s
> should be cut from stable master branch - it will ensure that we won=C2=
=B9t
> face last minute blockers as for 4.4, because master IS a stable branch.
> And yes, we should do merges instead of cherry picking.
>
>
>
>>
>


--=20
Daan