Re: ❌ FAIL: Stable queue: queue-5.2

[Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com>]

On 8/26/19 4:33 PM, Sasha Levin wrote:
> On Mon, Aug 26, 2019 at 02:39:31PM +0300, Nikolai Kondrashov wrote:
>> So, this leads me to suspect the repos *were* inconsistent. Likely not as I
>> described before, but still. They should've been inconsistent for more than 5
>> minutes for us to trip on this.
> 
> This is likely the case. I took my sweet time doing the release and
> looking at irc logs, I have gone way above 5 minutes. However, we'd
> really like to avoid having a magical number of minutes here to get it
> right.
> 
> To me the issue seems that you're mixing the information provided by two
> repos that may have inconsistency between them, even if merely due to
> sync within the CDN. You should use information provided only by one
> repo.
> 
> I myself run a (rather dumb) bot that just attempts to apply/build
> -stable tagged patches, and it seems to avoid the inconsistency issue by
> only working with the information provided by stable-queue:
> 
> - For each of the active stable/LTS kernels (let's say 5.2 in this
>    "loop"), we do:
> - Grab the latest released version from stable-queue:
>    - $ git tag | sort -V | grep 'v5\.2' | tail -n1
>      v5.2.10
> - Check it out in linux-stable:
>    - $ git checkout v5.2.10
>    - Bail if the above fails; this solves the "consistency" problem.
> - Apply the patches from the queue
> - Run your tests
> 
> This way, you guarantee that linux-stable is at the right position since
> you're just telling it where to go to, rather than getting information
> out of that repo which might conflict with something you've learned from
> stable-queue.

Thank you, Sasha. This makes sense. You using this approach in your bot gives
us the guarantee it will work :) We'll change our trigger to this (I posted an
internal ticket and everything), likely next week.

Nick