Philip McGrath writes: > Hi Chris, > > On 6/19/24 09:50, Christopher Baines wrote: >> Ludovic Courtès 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 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. Unfortunately I don't really have more insight on what went wrong initially. In case you haven't seen, you can see the queue of revisions to process here https://data.qa.guix.gnu.org/jobs/queue There's no requirement to wait for QA to process things, so I don't see it as overhead just yet.