I’ll get back to you on this thread tomorrow, late night here o/ Cheers.
On 05-Aug-2014, at 11:11 pm, Alena Prokharchyk <alena.prokharc...@citrix.com> wrote: > 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.prokharc...@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.namathpon...@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.da...@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.w...@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.c...@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.chaturv...@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.karut...@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 >>>>> >>>>> >>>> >>> >> > Regards, Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
