Block failing composes?

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:

  1. booting
  2. getting to a desktop
  3. 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
  4. 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.

Each Fedora CoreOS release is tested before being shipped so I would not worry about that here.

(Edit: The release process is not the same as Silverblue).

1 Like

F33 Silverblue is still definitely rawhide I believe, to the point @Siosm made.

F33 (including Silverblue) was branched from rawhide over a month ago, on 2020-08-11. https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html

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.