cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajani Karuturi <raj...@apache.org>
Subject Re: [DISCUSS] Release principles for Apache CloudStack
Date Fri, 03 Jul 2015 02:29:37 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message