cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <Alena.Prokharc...@citrix.com>
Subject Re: [VOTE] git workflow
Date Tue, 05 Aug 2014 21:11:55 GMT
Rohit, can you help us to figure out the advantages of implementation #2
(git workflow way of maintaining master branch) over implementation #1? As
per your words from other email "I was skeptic too and explored every bit
of the workflow and usage of git and I think it’s a good model” you might
have the answer :)

See details of implementation #1 and #2 below.

Thank you,
Alena.

On 8/5/14, 1:45 PM, "Alena Prokharchyk" <Alena.Prokharchyk@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
>* 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)
>
>
>It would be great if anyone can point the advantages of #2 approach over
>#1, as to me #1 seems to be the approach most people will find more
>intuitive and its used a lot in the field.
>
>-Alena.
>
>
>
>On 8/5/14, 1:22 PM, "Rayees Namathponnan" <rayees.namathponnan@citrix.com>
>wrote:
>
>>How frequent we can planning to merge from develop to master ?  during
>>release ?   
>>
>>Regards,
>>Rayees 
>>
>>
>>-----Original Message-----
>>From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
>>Sent: Tuesday, August 05, 2014 11:51 AM
>>To: dev@cloudstack.apache.org
>>Subject: RE: [VOTE] git workflow
>>
>>Sorry if this is already discussed, but few areas that are unclear to me
>>with this process are:
>>
>>- does every fix, however minor it be(say a signle line), needs to be
>>developed in a separate branch? And then we have to merge these
>>individual branches to develop for every fix?
>>- In that case will direct check-ins to 'develop' branch be not allowed?
>>- If not, if CI fails on develop branch, how will one know what caused
>>the failure? Was it some direct checkin Vs some feature/fix merged? Will
>>we revert all the small feature/fixes that were merged to develop branch
>>upto the CI baseline? If yes, wont the developers that did not cause the
>>break get penalized unnecessary?
>>
>>- Lastly, why can't this process be implemented on master? Why are we
>>introducing another branch for the same purposes which the master branch
>>usually serves?
>>
>>
>>I am -1 on this.  We should not start implementing this until all
>>processes are clear.
>>
>>Prachi
>>
>>-----Original Message-----
>>From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
>>Sent: Tuesday, August 05, 2014 11:33 AM
>>To: dev@cloudstack.apache.org
>>Subject: RE: [VOTE] git workflow
>>
>>Exactly. This just shifts pain from one branch to another.
>>I don't see any gains from this, either.
>>I vote "-1".
>>
>>Jessica
>>
>>
>>-----Original Message-----
>>From: Min Chen [mailto:min.chen@citrix.com]
>>Sent: Tuesday, August 05, 2014 11:27 AM
>>To: dev@cloudstack.apache.org
>>Subject: Re: [VOTE] git workflow
>>
>>Agree with Animesh. Didn't see any gains from this, we just shift pain
>>from one branch to another, so vote -1.
>>
>>-min
>>
>>On 8/2/14 9:50 PM, "Animesh Chaturvedi" <animesh.chaturvedi@citrix.com>
>>wrote:
>>
>>>+0
>>>
>>>While this protects master with only commits which are merges from
>>>release branch and keeps it clean but the issues that we have shift to
>>>develop branch.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Rajani Karuturi [mailto:Rajani.Karuturi@citrix.com]
>>>> Sent: Thursday, July 31, 2014 3:28 AM
>>>> To: dev
>>>> Subject: [VOTE] git workflow
>>>> 
>>>> Hi All,
>>>> 
>>>> We had long discussions on the git flow.
>>>> I tried to capture the summary of it @
>>>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>>>> This is updated on wiki @
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>>>> ProposedGitflowbasedCheck-inProcess and is up for a vote:
>>>> 
>>>> Can you share your opinion on the proposal?
>>>> 
>>>> [ ] +1  approve
>>>> [ ] +0  no opinion
>>>> [ ] -1  disapprove (and reason why)
>>>> 
>>>> 
>>>> Thanks,
>>>> ~Rajani
>>>> 
>>>> 
>>>
>>
>

Mime
View raw message