Re: ❌ FAIL: Stable queue: queue-5.1

[Veronika Kabatova <vkabatov@redhat.com>]

----- 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
>