Open Stack

Hi,

> On 1 Jul 2019, at 17:03, Clark Boylan <cboylan at sapwetik.org> wrote:
> 
> On Mon, Jul 1, 2019, at 7:55 AM, Slawek Kaplonski wrote:
>> Hi,
>> 
>>> On 1 Jul 2019, at 15:08, Jeremy Stanley <fungi at yuggoth.org> wrote:
>>> 
>>> On 2019-07-01 14:44:29 +0200 (+0200), Slawek Kaplonski wrote:
>>> [...]
>>>> Patch [2] is proposed so now lets wait until it will be merged and
>>>> You can than rebase Your neutron patches to make Zuul happy again
>>> [...]
>>> 
>>> There should be no need to rebase changes for Zuul to make use of a
>>> fix which merges to the branch. Just a "recheck" comment is all you
>>> need. Zuul always merges your change onto the latest branch state
>>> when starting new builds, so the *only* reason to rebase should be
>>> if you have a legitimate merge conflict preventing it from being
>>> tested at all. This is not new, this is the way Zuul has always
>>> worked.
>> 
>> So if I have fix for some issue in Neutron repo (lets say patch A), and 
>> other patch to neutron repo (patch B) which is failing because of this 
>> issue, I don’t need to rebase my failing patch B to include fix from 
>> patch A and to get +1 from Zuul? Am I understanding correct what You 
>> wrote?
>> I know that it is like that in gate queue but I though that in check 
>> queue it works differently.
> 
> You don't need to rebase or use depends on once change A has merged because Zuul will always merge your proposed changes (change B) to the target branch (which includes change A).

Thx a lot for explanation. I didn’t know that it is like that in check queue :)

> 
> If you want things to go green prior to change A merging you will need to rebase or use depends on.
> 
> Clark

— 
Slawek Kaplonski
Senior software engineer
Red Hat