----- 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.16The results of these automated tests are provided below.
Overall result: FAILED (see details below) Merge: FAILEDGuys, 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