Can we please block composes from being released (as a downloadable ISO and to the server that hosts our upgrades) if the composes do not pass tests?
This should include testing the following:
booting
getting to a desktop
toolbox create & run & dnf update
…of the currently running version of Fedora
as of F33 branching, it would be Fedora 33, not rawhide
…of the previous version of Fedora
in the F33 beta, it would be the equivalent of: toolbox create previous -r 32
installing & running a flatpak
When I’m using Silverblue, I usually don’t have problems, but I have experienced issues 1 - 3 in the past few weeks: I had booting problems 1 & 2 as early as this morning (Latest F33 build (33.20200915.n.0) fails to boot) and toolbox issues a week or two ago.
Yes, this would prevent us from getting some updates (for a little bit), but it’s better than having a system that doesn’t work (without intervention).
Issue 1 & 3 should apply for CoreOS and IoT as well.
I see that CoreOS has different release streams for stable, testing, and unstable. Is this something that Silverblue could do also? I also do not like updates that break things and even SB 32 sometimes (often?) breaks things like toolbox because podman is still undergoing significant development changes. This may also benefit development of new technologies like pipewire, etc… Do you think this is possible direction for Silverblue?
Yes, I saw that, but bodhi still hasn’t successfully built a F33 release candidate for beta so we are in that grey area between rawhide and beta rc. Or a rock and a hard place.
[Edit]: 33.20200917.n.0 is failing also. Locks screen during boot, no tty available to troubleshoot from.