On Wed, Dec 2, 2020, at 12:19 PM, Adam Williamson wrote: > > > What does the question "is Fedora CoreOS 34 ready to go" even mean, in > the context of how CoreOS is built and released? What set of bits will > we be deciding to ship or not ship, and how will that have been decided > and communicated? Where will we look to find the test results and > criteria on which we would base that decision? There are a whole lot of aspects to this, but one angle to look at this from is that I personally have always thought the way Fedora uses pungi up until releases and everything's about a "compose" and then it switches to a Bodhi wild west where updates are unversioned things that can release at any time...well, it doesn't make much sense. The concept that you have boot media that can reach 6 months old is a very bad anti-pattern because there are often periods of time where the software there has security vulnerabilities. *Particularly* for a desktop system starting up a 6 month old web browser is just actively dangerous. Now I understand there are reasons traditional Fedora does this - among them that Anaconda is a huge thing on its own. But for FCOS we made a massive simplification - the "Live" FCOS *is the same thing as the OS*. Our `coreos-installer` is just a glorified `dd` wrapper (mostly) and all system provisioning logic happens in Ignition, which we're constantly testing all of the time. (Personally I'm really proud that for example our Live ISO ships with SELinux enforcing) FCOS currently respins both an ostree commit and boot media every release, and because we use coreos-assembler all the time, those are all strongly versioned together and consistent. Beyond the pungi-vs-bodhi thing of course, to me it is also very fundamental that our OS build and test process runs natively via podman and Kubernetes (unprivileged). We're telling people to use containers; building the operating system shouldn't require you to `yum install` (or even `rpm-ostree` install stuff directly on a host system. Our current build pipeline is Jenkins-running-in-OpenShift; we're actively working on removing Jenkins from the equation in some circumstances and making the whole thing even more Kubernetes-native. This is not at all true of the Koji/pungi stack. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
