On Jul 3, 2015, at 9:06 AM, Raja Pullela <raja.pull...@citrix.com> wrote:
> Remi, > > couple of questions on the branching part - when we take the Feature PR and > Feature is back in Master, feel like we are potentially destabilizing Master > ? I know, currently we push changes to master even before anything is > tested fully - agree, we are now running the Travis test before a checkin - > however, I feel those are not sufficient ? > > IMHO - we should take a release branch open it up for PR/checkins and once > the testing is done the branch gets into Master - we take RC from the master > and release it. That way no one checkins to master and constantly tested > changes get into/merged to master. > > I remember seeing similar changes proposed by few folks... I have been little > out of touch on those changes. > Basically yes, we should not merge untested, unfinished features in master. > best, > Raja > -----Original Message----- > From: Rajani Karuturi [mailto:raj...@apache.org] > Sent: Friday, July 3, 2015 8:00 AM > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] Release principles for Apache CloudStack > > I do not agree to backporting aka cherry picking. I prefer forward > merges(tofu scale) 4.4 to 4.5 to master etc. > That way, none of the changes will be missed and git branch --contains gives > a nice view of where all the changes went. > > > On Thu, Jul 2, 2015 at 23:16 PM, Remi Bergsma <r...@remi.nl> wrote: > > Hi Daan, > > Indeed. I prefer committing to master first, as it will ensure everything > ends up there (unless some specific use cases). Currently, we have the risk > of forgetting to include a fix to a release branch back to master. > > When we reverse it, some bug fix that should end up in the x.y branch, is > committed to master, then also applied (or reimplemented) to x.y. If you then > only take one of the two steps, there is no issue as it will be in master > only (and people will notice). In the other situation, when we accept a PR to > x.y and forget to merge back, we possibly introduce regression bugs. > > I will update the diagram and wiki later tonight. > > While reviewing PRs, let’s be alert to see PRs not pointed towards master and > at least discuss it. > > Regards, > Remi > > >> On 2 jul. 2015, at 16:54, Daan Hoogland <daan.hoogl...@gmail.com > <javascript:;>> wrote: >> >> On Thu, Jul 2, 2015 at 2:29 PM, Remi Bergsma <r...@remi.nl >> <javascript:;>> > wrote: >>> Since the goal is a stable master, I’d say the bug fix should go to > master first. >> >> >> Remi, this means that merge back of the branch makes no sense anymore. >> >> -- >> Daan > > > > -- > - > Sent from Windows Phone > ~Rajani
