----- Original Message -----

From: "Greg KH" gregkh@linuxfoundation.org To: "CKI Project" cki-project@redhat.com Cc: "Linux Stable maillist" stable@vger.kernel.org Sent: Wednesday, July 3, 2019 1:25:20 PM Subject: Re: ❌ FAIL: Stable queue: queue-5.1

On Wed, Jul 03, 2019 at 07:16:58AM -0400, CKI Project wrote:

...

Hello,

We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to:

   Kernel repo:
   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
        Commit: 8584aaf1c326 - Linux 5.1.16

The results of these automated tests are provided below.

Overall result: FAILED (see details below)
         Merge: FAILED

Guys, this is getting annoying, this is your test systems, the queue is empty :)

Hi,

this is not an empty queue problem (that should be fixed now). We triggered the testing right after the 5.1.16 was released to test the present queue with it. We have added the commit hash of the queue to the merge details in the report to verify this is indeed the case.

The base commit for the stable kernel is 8584aaf1c326 The commit of the stable queue is d0f506ba82

This queue was removed a minute later (obviously with the release) after the baseline change was pushed but we caught this combo as we try to trigger testing after every change to any of those repos. So the patches from the queue really didn't apply.

I currently see two ways (or their combination) around this: 1) The queue changes need to be pushed first 2) We detect how long ago the baseline was pushed and if it's less than let's say 5mins we abort the pipeline to give you enough time to do the changes to the repo

Maybe you also have a different idea that would work better? We try to keep up with your quick changes to really test everything and in this case ended up being too fast.

Thanks for the feedback and working with us so we can figure out a workflow that works the best for you,

Veronika

thanks,

greg k-h

----- Original Message -----

From: "Greg KH" gregkh@linuxfoundation.org To: "Veronika Kabatova" vkabatov@redhat.com Cc: "CKI Project" cki-project@redhat.com, "Linux Stable maillist" stable@vger.kernel.org Sent: Wednesday, July 3, 2019 2:07:59 PM Subject: Re: ❌ FAIL: Stable queue: queue-5.1

On Wed, Jul 03, 2019 at 08:01:16AM -0400, Veronika Kabatova wrote:

...

----- Original Message -----

...

From: "Greg KH" gregkh@linuxfoundation.org To: "CKI Project" cki-project@redhat.com Cc: "Linux Stable maillist" stable@vger.kernel.org Sent: Wednesday, July 3, 2019 1:25:20 PM Subject: Re: ❌ FAIL: Stable queue: queue-5.1

On Wed, Jul 03, 2019 at 07:16:58AM -0400, CKI Project wrote:

...

Hello,

We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to:

   Kernel repo:
   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
        Commit: 8584aaf1c326 - Linux 5.1.16

The results of these automated tests are provided below.

Overall result: FAILED (see details below)
         Merge: FAILED

Guys, this is getting annoying, this is your test systems, the queue is empty :)

Hi,

this is not an empty queue problem (that should be fixed now). We triggered the testing right after the 5.1.16 was released to test the present queue with it. We have added the commit hash of the queue to the merge details in the report to verify this is indeed the case.

The base commit for the stable kernel is 8584aaf1c326 The commit of the stable queue is d0f506ba82

This queue was removed a minute later (obviously with the release) after the baseline change was pushed but we caught this combo as we try to trigger testing after every change to any of those repos. So the patches from the queue really didn't apply.

I currently see two ways (or their combination) around this:

1. The queue changes need to be pushed first

Given that you are working behind a mirror of the "real" git trees, they can, and probably will, get out of order, so there's no guarantee of "first" here.

And I am doing this in a scripted way, so they should be pushed within 1 minute of each other at this point in time.

...

2. We detect how long ago the baseline was pushed and if it's less than let's say 5mins we abort the pipeline to give you enough time to do the changes to the repo

I say this is the best thing to do to help with the mirroring issues involved.

Given the additional info you just mentioned I agree that this is the most reasonable solution. I'll work on implementing this as soon as I find some free time.

Thanks again! Veronika

thanks,

greg k-h