On Fri, Dec 22, 2023 at 01:34:09PM +0000, Marc Zyngier wrote: > On 2023-12-22 13:26, Mark Brown wrote: > > On Fri, Dec 22, 2023 at 01:16:41PM +0000, Marc Zyngier wrote: > > > > Oliver, should your tree be in -next? > > > No, we don't have the KVM/arm64 fixes in -next. > > I see it's not, I'm asking if it should be - given the latencies > > involved it seems like it'd be helpful for keeping -next working. > This is on purpose. We use -next for, well, the next release, > and not as a band-aid for some other purpose. If you think things Note that -next includes pending-fixes which is specifically for the purpose of getting coverage for fixes intended to go to mainline (indeed this issue was found and reported before the original problematic patch was sent to mainline, it's not clear to me what went wrong there). As well as the fixes getting coverage through being in -next itself there's a bunch of the CI that specifically looks at pending-fixes, trying to both prioritise keeping mainline stable and catch things like unintended dependencies on things only in -next. There's also the fact that if mainline is broken and not somehow fixed in -next then that does disrupt the use of -next for testing things aimed at the next release. > don't get merged quickly enough, please take it with the person > processing the PRs (Paolo). He is on CC here. I'm not sure that it's specifically things not getting merged (well, modulo this one fixing an issue in mainline) - it's a totally reasonable approach to want to give things time to get reviewed and tested before they get merged, but if we're doing that then it seems sensible to take advantage of the coverage from having things in the integration trees. OTOH if things get merged very quickly then it's less clear since there's less time for the integration trees to do their thing. It feels like things aren't lining up well here. > > > And we have another two weeks to release, so ample amount of > > > time until Paolo picks up the PR. > > Sure, but we do also have the holidays and also the fact that it's a > > build failure in a configuration used by some of the CIs means that > > we've got a bunch of testing that simply hasn't been happening for a > > couple of weeks now. > Given that most of the KVM tests are usually more broken than > the kernel itself, I'm not losing much sleep over it. That's suprising to me, other than this release it doesn't match my experiences too well - there is a bit of glitchiness in one of the dirty_log tests on some platforms but otherwise the KVM selftests are generally rather stable on the systems where I pay attention to the results. They're certainly not a testsuite I expect to have to frequently worry about - we might wish for more coverage but that's something different to brokenness. The build issues during this release cycle have been a bit of an exception.
Attachment:
signature.asc
Description: PGP signature
