cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebgoa <run...@gmail.com>
Subject Re: [DISCUSS] Release principles for Apache CloudStack
Date Fri, 03 Jul 2015 07:21:44 GMT

On Jul 3, 2015, at 9:06 AM, Raja Pullela <raja.pullela@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:rajani@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 <remi@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.hoogland@gmail.com
> <javascript:;>> wrote:
>> 
>> On Thu, Jul 2, 2015 at 2:29 PM, Remi Bergsma <remi@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


Mime
View raw message