Re: qa.guix delays in processing patches

[Philip McGrath]

Hi Chris,

On 6/19/24 09:50, Christopher Baines wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
> > It’s unclear to me why issues are sometimes seemingly not picked up.
> > Chris, do you have more insight into this?
>
> QA just looks at a small number of latest series [1] and those
> associated issues so I'm guessing in this case the patch series was old
> enough for QA not to be looking at it. This is mostly due to disk space
> limitations for data.qa.guix.gnu.org.
>
> 1: 
> https://git.savannah.gnu.org/cgit/guix/qa-frontpage.git/tree/scripts/guix-qa-frontpage.in#n154
>
> Unfortunately the messaging is rather poor in this circumstance.

I'm not sure this explains why the job was dropped after having been 
picked up, as I (belatedly) mentioned in my reply to Ludo’:

https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00203.html

> I should have mentioned this in my last email, but, when I first sent the patch 
> series, it *had* been picked up as https://qa.guix.gnu.org/issue/71203 and 
> gotten to the "yet to process revision" state. I checked in on it a few times, 
> and it remained in that state: only the last time (before rebasing) did it say 
> "issue not found", though I'm not sure how long it had been since I'd last 
> checked. I guess one thing I'm realizing is I don't know how long is normal for 
> QA to take vs. when I should report a potential problem.

On that last point, it's now been over a week since I rebased the 
series, and <https://qa.guix.gnu.org/issue/71203> is still in the "yet 
to process revision" state. Is this normal?

At least a few revisions created later seem to have reached "success":

https://data.qa.guix.gnu.org/revision/003695a6a66ab2a69506d2f5a689170ccc340505

https://data.qa.guix.gnu.org/revision/d0e425b0f538a8762e3199f5223597835cfe75da

(The later seems to have "start"ed after the patch had already been merged.)

It's not clear to me how jobs are ordered in the queue, which makes it 
hard to tell if this is normal processing time or if something might be 
going wrong again.

I think there can be a lot of value in QA, especially in catching 
regressions on architectures I don't have available. But, even ignoring 
the additional delay waiting for the May 26 job that disappeared, this 
feels to me like a disproportionate overhead for a routine package update.

Thanks,
Philip