ter?
>
> Best Regards,
> Sanjeev N
> Chief Product Engineer, Accelerite
> Off: +91 40 6722 9368 | EMail: sanjeev.neelar...@accelerite.com
>
>
> -Original Message-
> From: Remi Bergsma [mailto:rberg...@schubergphilis.com]
> Sent: Monday, March 28, 2016 1:24 PM
> To:
[mailto:rberg...@schubergphilis.com]
Sent: Monday, March 28, 2016 1:24 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] PR testing process
Indeed. If a merge fails then you'll not be able to merge it to master or
another release branch later on anyway so the author must rebase against the
Indeed. If a merge fails then you'll not be able to merge it to master or
another release branch later on anyway so the author must rebase against the
base branch first. No need spending test cycles on that.
Most likely github already reports that PR as 'unstable' so you could also
check for t
To be more exact: Merge to the base branch the PR was created against. Could be
master, could be 4.7 and such. The code snipped I linked to also does that.
Sent from my iPhone
> On 28 Mar 2016, at 09:13, Remi Bergsma wrote:
>
> Hi Sanjeev,
>
> I’d propose taking the latest master, ensure it
Hi Sanjeev,
Thanks for bringing this up.
This is happening because the PR code and the master have deviated since the pr
has been created(assuming that PR was rebased with master at the time of
creation) and we start testing it. Ideally we should start testing as soon as
the pr is created but
Hi Sanjeev,
I’d propose taking the latest master, ensure it is up2date, make a temp branch
then merge the PR to be tested on that. This ensures you test the result of the
merge, like it will happen om master.
For the merging, use the same script we use when we merge for real:
https://github.com
