How about that?
I'd like to play it conservative when it comes to stabilizing a library package. That is, in the absence of security issues (or other issues that would require a newer version to be stabilized), I wait until the stabilization request trickles down from an package using the library package. That said, I am not aware of any reasons against stabilizing 2.3. So if anyone wants to trigger it by adding CC-ARCHES to the bug's keywords, then be my guest. Of course, help with any potential fallout due to that is then expected. :-P
That's not how we operate in general, not even for system critical libraries. But I'm not in a hurry, there is no EAPI-7 backlog here and I just noticed 2.3 existed in tree since Nov '22.
Unable to check for sanity: > no match for package: sys-libs/liburing-2.3-r1
Bumping to -r2 for commit 0f71a9212efeed4fb1d7a7790d327d397cf92234
Unable to check for sanity: > no match for package: sys-libs/liburing-2.3-r2
All sanity-check issues have been resolved
Given tests are new, I suspect bug 894374 isn't actually a regression.
arm64 done
arm done
amd64 done
x86 done
I'm going to close this bug for now despite ppc* & sparc not being done because we suspect it's causing kernel hangs on both. I'll open another bug for that now but I don't want the automated testing to keep picking up this bug.