Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of Alena.Prokharchyk@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Alena Prokharchyk <Alena.Prokharchyk@citrix.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Subject: Re: [VOTE] git workflow
Thread-Topic: [VOTE] git workflow
Thread-Index: 
 AQHPrKoeOmMyssWoyUmi+oxPr/ByV5u+Ua3ggAQKiQCAAADVsIAArvwA//+Z5yCAAISFgIAAGW2AgABGHwCAABF0AIAAAh4AgAA4XoCAAHqJgP//joKAgAB/XICAAARUgP//jMsAABAKC4D//44/gIAAfekA//+MjgA=
Date: Wed, 6 Aug 2014 19:59:12 +0000
Message-ID: <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>
In-Reply-To: 
 <CAP997UcDb56P5NtjKJfuhnaV0vum5AkXnmST9CgdFO9fFqE+3g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.4.1.140326
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <CC6AD0893AD30F47A19DB354423B8DC0@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


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.
>
>--=20
>Erik

I=B9m not arguing against keeping master release stable; I advocate for it.
But we can=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 branches
should be cut from stable master branch - it will ensure that we won=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.


>