Hi

On Fri, Aug 22, 2025 at 05:22:54PM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
> On 22/08/2025 16:54, Michael Niedermayer via ffmpeg-devel wrote:
> > Hi Timo
> > 
> > On Fri, Aug 22, 2025 at 02:13:14PM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
> > [...]
> > > But then again, GitHub/MS gives us 20 parallel runners for free, and we can
> > > freely pick if they're running on x86_64 or aarch64, Linux, Windows or even
> > > OSX.
> > > As long as they do that, we only need to host a baseline of runners
> > > ourselves, and can scale out into that whenever there's a peak in usage.
> > 
> > if they give us 20, can we test mips & arm with qemu in a way that it
> > does not block or delay merges.
> > 
> > I mean so that a pr is considered ok and mergeable before tzhe slow qemu
> > fate finishes but after the 2h or so it will display the result in the pr

> We could only run those tests on master, not on PRs.
> Nobody is impacted by them then, and we still notice breakage reasonably
> fast.

yes, agree


> 
> For arm I'm not sure if we really need qemu? All it might take is a 32bit
> arm chroot on aarch64? Not sure if it works like x86 though, where a 64bit
> CPU can also run 32bit code.

yeah i thought the same a few moments after sending that mail, though i
have never tried

i guess riscv would then be the next on the list to have at least a build test

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.