Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
MIME-Version: 1.0
In-Reply-To: <5A0007D9-DD72-4742-BD91-70E21E495D21@remi.nl>
References: <F18BF32A-6962-4DBF-8014-E815EF19AC4A@remi.nl>
 <C7522783E0E6D3488D82B9A7F7F004B9341661ED@SINPEX01CL01.citrite.net>
 <CAP997UdpnhV6ii2sLMRZ9V-3zrJvaEoQqbu9AY2tUM_WMFdneA@mail.gmail.com>
 <E34E75E0-CBE9-49B8-962F-601D281B3FFA@remi.nl>
 <CAGQtxvb5hKGPEM4X93tzfzNQrbCEQW6G7QiWXiGaAC=cezeXmw@mail.gmail.com>
 <FB9E5054-2B1C-4E7A-807B-01A7A374793C@remi.nl>
 <CAPpf5a2Zgteieckbdsbbb6vCiy+FhD33CyF=d_xEsLJswaB9Cg@mail.gmail.com>
 <5A0007D9-DD72-4742-BD91-70E21E495D21@remi.nl>
From: Rajani Karuturi <rajani@apache.org>
Date: Fri, 3 Jul 2015 16:31:46 +0530
Message-ID: 
 <CAPpf5a0GbhVQBumz70yAk4HPX67oVu2EAZLsoDg-s7xDfFDy=w@mail.gmail.com>
Subject: Re: [DISCUSS] Release principles for Apache CloudStack
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=089e0111b2a28a4b0e0519f67c99

--089e0111b2a28a4b0e0519f67c99
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree to the goal. No regressions can be achieved either by cherry-picks
or merges. Both requires developers to agree to it and has equal
probability to miss.

The advantage in case of merge is, lets say you do a commit a1 to 4.5
branch and forget to merge to master. now, someone else did a2 and is
trying to merge. He will see both the commits and can make choice either to
ask about a1 or merge both.
may be if the merge has conflicts or is not a clean merge, it can be done
as PR which follows the usual process.

with respect to refactoring, we can always do separate PRs on master and
the release branch. The merge from release branch to master in this case
would be an empty merge (git merge -s ours)

The problem I see with the current approach is its not always backporting
the fix to release. This works if the issue reported is already known and
fixed on master or any forward releases.
Usually, you work on a release branch only when an issue is reported on it.
For a issue reported on 4.5, first thing I do is check if the issue really
exists in 4.5 and would also find the solution around the same time. Its
sounds natural to me to push to 4.5(get the load off your head whether it
is customer issue or security issue) and then merge to forward releases.
Now, with the new process, I will have to first verify if the bug exists in
the current release+1, fix in it first, then go back to release branch,
verify if it exists and fix it there.
Obviously there would be exceptions in merging and you may have to
cherry-pick once in a while. But, making it the process is what concerns me=
.


In addition to the goal mentioned, I would also like to find which all
versions the commit is present in.
For example, If a security issue is reported on 4.5, I found that this is a
regression from commit abcde. Now, I would like to find which all version
this is present as this security patch should be delivered on all the
versions.
In the current situation and also in the new process suggested, the only
way to find it is to go to each and every release and see if the commit is
present.
In the merge route, its simple git merge --contains abcde

Merging is not easy. It requires discipline. But, it has benefits. If
everyone follows it, its as easy as cherry-picking as the code diff will be
exactly same.


Maintaining a release is the second part of the story :) I do agree with
you on the release process for 4.6. Lets start with it for 4.6 release and
continue discussing on how we want to maintain 4.6.x(may be we would never
need one ;))

I can volunteer to be the additional RM for 4.6.


~Rajani

On Fri, Jul 3, 2015 at 1:36 PM, Remi Bergsma <remi@remi.nl> wrote:

> Hi Rajani, all,
>
> I do think we have the same goal in mind: no regression and no cherry-pic=
k
> mess.
>
> Just did some reading on "tofu scale" and see two issues:
> - if it doesn't happen / isn't completed we'll have regression as we've
> seen before. I want a working model that prevents regression by default o=
r
> else we will not reach smooth upgrades without introducing old bugs again=
.
> - we are doing lots of refactoring work (probably will be doing even more=
)
> where this model also will not work because the merge fails to apply
> cleanly (this is what Erik mentioned yesterday). Fixing that conflict is
> invisible on the dev-list (as we have no PR) and error prone (not tested
> before commit, no LGTMs).
>
> Don=E2=80=99t get me wrong, I don=E2=80=99t want the cherry-pick mess we =
experienced
> before.
>
> What will be different:
> - master is stable instead of unstable
> - we=E2=80=99ll branch off x.y (say 4.6 which is up next) only after a vo=
te on a
> RC passes. Instead of branching it off first, then make it stable and
> release it and cherry-pick stuff around. So, no cherry-picking here.
> - once the x.y branch is there, we should do no back ports of features.
> Only (critical?) bug fixes.
>
> Those bug fixes (that went to master first through PR and got 2x LGTM)
> could now also be applied to the x.y. branch (and become x.y.1 or similar=
)
> Instead of cherry-picking, I=E2=80=99d apply the same PR to x.y (if possi=
ble, or
> else a new PR that reimplements the fix for x.y in which case it would ne=
ed
> its own 2x LGTM). In any bug fix PR we should mention the jira bug id (an=
d
> PR id) in the commit message. This, you could argue, is like cherry-picki=
ng
> as it makes a new commit id. As the amount of bug fix commits should me
> minimal, I think this is ok.
>
> We should make sure upgrades are so smooth that our users can upgrade
> easily and we don=E2=80=99t have to maintain previous releases for a long=
 time.
>
> I clarified some more things on the wiki and also updated the diagrams.
>
> Regards,
> Remi
>
>
> > On 3 jul. 2015, at 04:29, Rajani Karuturi <rajani@apache.org> wrote:
> >
> > 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 <mailto:
> remi@remi.nl>> wrote:
> >
> > Hi Daan,
> >
> > Indeed. I prefer committing to master first, as it will ensure everythi=
ng
> > 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 yo=
u
> > 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=E2=80=99s be alert to see PRs not pointed towa=
rds 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 <mailto:
> remi@remi.nl> <javascript:;>>
> > wrote:
> >>> Since the goal is a stable master, I=E2=80=99d 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
>
>

--089e0111b2a28a4b0e0519f67c99--