Re: Xen 4.18 release: Reminder about last posting date

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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/AS8PR08MB79919F9CE0B2BF80E7103FB592609@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> >>> [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.


> >> 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.)

.qemu-arm64 and .qemu-arm32 are the only ones using unstable/rolling
containers in automation/gitlab-ci/test.yaml (excluding .qemu-riscv64),
that's why I was asking about those two specifically.


> Then the second part which is also a blocker.  Update the distros we
> test with to be less obsolete.  e.g. the majority of our CI testing runs
> with Alpine-3.12 when EOL more than a year ago. (2022-05-01)

OK. Hopefully it will be trivial.