On 09/08/2023 11:34 pm, Stefano Stabellini wrote: > On Wed, 9 Aug 2023, Andrew Cooper wrote: >> On 09/08/2023 10:43 pm, Stefano Stabellini wrote: >>> On Wed, 9 Aug 2023, Andrew Cooper wrote: >>>> On 07/08/2023 2:24 am, Henry Wang wrote: >>>>> Hi everyone, >>>>> >>>>> Following the release schedule discussion in in April, I am sending this >>>>> email >>>>> to remind that according to the release schedule [1], August 11 (this >>>>> Friday) >>>>> will be the last posting date, when patches adding new features are >>>>> expected >>>>> to be posted to the mailing list by this date. >>>>> >>>>> Also, note that we currently have 1 release blocker [2] which might need >>>>> some attention. >>>>> >>>>> [1] >>>>> https://lore.kernel.org/xen-devel/as8pr08mb79919f9ce0b2bf80e7103fb592...@as8pr08mb7991.eurprd08.prod.outlook.com/ >>>>> [2] https://gitlab.com/xen-project/xen/-/issues/114 >>>> Off the top of my head. >>>> >>>> There are still unaddressed Gitlab bugs from the Eclair integration >>> The bug you managed to find it is now fixed (commit e55146071de9). I am >>> all for fixing Gitlab bugs so let me know if you find anything else! I >>> am not aware of any other issue with Eclair at the moment. >> I meant the one where Eclair is still running on `smoke` and twiddling >> its thumbs for 1h doing so each time OSSTest says yes to a push. It >> will be a missing 'exclude' somewhere, but I haven't hand enough time to >> look. > Ah, yes, got it. I would call it "Eclair lagging behind". I am happy for > this to be a blocker.
Something else for the list is to see about trimming down the testing we're doing. I had to cancel 7 pipelines (mostly patchew) in order to get a gitlab run on a late-breaking tweak on the security content yesterday. Take https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/959800176 as an example. Nearly 2h to run, and queued for 2h before that waiting to start. This is not a rare occurrence right now. >>>> and other Gitlab bugs (use of unstable containers) which I'd unwilling >>>> to let 4.18 be released with, given the pain we've had on the stable >>>> trees trying to keep CI working. >>> That is fair enough. To make this more concrete and easier to track, the >>> following would need to be changed to using stable containers: >>> >>> - .qemu-arm64 >>> - .qemu-arm32 >>> (I am not counting .qemu-riscv64) >>> >>> Andrew, is that what you meant? Am I missing anything? >> Every debian unstable container, and the other containers (OpenSUSE) >> which are using an non-specific upstream version. Upstreams which >> really are rolling distros (Arch, Tumbleweed) need to be made non-fatal. > I was more asking whether for 4.18 you want to fix only test.yaml or > also build.yaml. (Typically it is test.yaml that causes most issues > with rolling containers.) Everything. Because both bite equally hard in stable trees. It's not hard to do - just needs some time. ~Andrew
