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 >>>> >>>> >>> >> >
