----- Original Message ----- > From: "Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx> > To: "Veronika Kabatova" <vkabatov@xxxxxxxxxx> > Cc: "CKI Project" <cki-project@xxxxxxxxxx>, "Linux Stable maillist" <stable@xxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxxxxxx> > > > To: "CKI Project" <cki-project@xxxxxxxxxx> > > > Cc: "Linux Stable maillist" <stable@xxxxxxxxxxxxxxx> > > > 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 >
