Re: [PATCH v2] Re-enable riscv64-debian-cross-container (debian riscv64 is finally usable again!)

[Daniel P . Berrangé]

On Fri, May 03, 2024 at 10:51:57AM +0200, Philippe Mathieu-Daudé wrote:
> On 3/5/24 10:07, Daniel P. Berrangé wrote:
> > On Fri, May 03, 2024 at 10:16:34AM +0300, Michael Tokarev wrote:
> > > Revert "gitlab-ci: Disable the riscv64-debian-cross-container by default"
> > > This reverts commit f51f90c65ed7706c3c4f7a889ce3d6b7ab75ef6a.
> > > 
> > > riscv64 in debian has been non-functioning for almost a year, after the
> > > architecture has been promoted to release architecture and all binary
> > > packages started to be re-built, making the port not 
> > > multi-arch-co-installable
> > > for a long time (in debian, multi-arch packages must be of the same 
> > > version,
> > > but when a package is rebuilt on one architecture it gets a version bump 
> > > too).
> > > Later on, debiah had a long time64_t transition which made sid unusable 
> > > for
> 
> "debian" (even "Debian")
> 
> > > quite some time too.  Both such events happens in debian very rarely 
> > > (like,
> > > once in 10 years or so - for example, previous big transition like that 
> > > was
> > > libc5 => libc6 transition).  Now both of these are finished (where qemu is
> 
> ("QEMU")
> 
> > > concerned anyway).
> > > 
> > > Hopefully debian unstable wont be very unstable.  At the very least it is
> > > better to have sporadic CI failures here than no riscv64 coverage at all.
> > 
> > IME of running Debian sid in CI pipelines for libvirt, it is
> > way too unstable to be used as a gating job. There are periods
> > weeks-long when packages fail to install, even for relatively
> > mainstream arch targets like x86, let alone a new target like
> > riscv.
> > 
> > Running the job by default is sane, but it should not be made
> > gating until in a formal Debian release IMHO.
> 
> So it is waste of resources, and each time maintainers will look
> for failure and notice "oh this is still this broken image" and
> skip. Hard to see the gain of bringing that back TBH.

Michael has indicated he wants to see the result of testing of riscv,
to validate stable releases don't regress.

Having it non-gating allows the possibility to look at the job and
evaluate whether a failure is due to genuine bugs, or distro problems.

Having it gating guarantees the the pipeline overall is going to be
marked failed whenever distro problems hit, which is worse as it
impacts everyone using CI.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|