On Wed, 2020-12-02 at 19:42 +0100, Clement Verna wrote: > > > > CoreOS is going to be the same only worse, because it's not even built > > the same way as the rest of Fedora. It's not built by Pungi, we don't > > get the same messages published when CoreOS builds happen (we don't get > > messages published at all, IIRC), the metadata for CoreOS builds is not > > in productmd[2] form like the metadata for Pungi builds, the whole > > process is entirely different. > > > > Recently messages were added when streams are updated [0][1]. I believe > that other messages could be added if needed. Right, I forgot about that, thanks. I've got a ticket lying around here somewhere to make something actually use them...:) > > > > So to boil this down into a representative question: when we are doing > > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide > > whether to release "Fedora CoreOS 34"? > > > > > Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing and > next, each stream is released every 2 weeks. > The Go/No-Go is based on reports coming from each stream, next stream is > promoted to testing and testing promoted to stable. > If any blockers are found in next or testing the content will not be > promoted to stable. > > I think it is fairly well explained here[2] > > > > 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? > > > > > To maintain a fortnightly cadence there is a strong reliance on CI, every > build is tested and results are inspected during the release process. > Currently a release is gated on tests running on AWS, GCP and Openstack, > these tests are running on a centos-ci jenkins instance which I think > cannot be access without a centos account (I might be wrong), but yeah > making these tests and results more transparent could be an improvement. Right, but - as I think you started to recognize later in your mail - we're sort of talking at cross-purposes here. You're talking about a process that has been developed kind of in isolation for building and releasing a thing which has the name "Fedora CoreOS" but doesn't actually really integrate much at all with the processes we have for building and releasing all the other things that make up "Fedora". This is kind of fine as things stand because the thing with the name "Fedora CoreOS" isn't considered to be a core fundamental part of the thing with the name "Fedora". But this Change is about making it that. Doing that causes all sorts of awkward impedance mismatches. Like, saying "Fedora CoreOS 34 does not exist" is awkward, because we still have this kind of institutional concept of a "Fedora release" which is important to what the thing called "Fedora" is and does. To the outside world, there is a strong impression that the thing called "Fedora" is a product or set of products with a release number that gets released every six months. The concept of "Fedora 33 release" or "Fedora 34 release" is a strong concept with all these sort of institutional ripples. If we want the thing called "Fedora CoreOS" to be a key, fundamental component of the thing called "Fedora" - which is what making it an "Edition" is effectively about - we have to deal with those impedance mismatches. So in this case, we could, for instance, make "Fedora CoreOS 34" a 'thing' by requiring that the CoreOS stable stream gets bumped at the same time as the rest of the Fedora "release" happening. That gives us a nice simple story that fits into our existing way of doing things. This is more or less what we did with IoT: as things stand, the situation with IoT is "OK, it's built from a separate compose stream, but we still expect it to tie into the release cycle. We expect there to be a release candidate based on the same bits as the mainline release, with the same release number, that we sign off and release at the same time." Of course, that's also the drawback. If we don't want to do that, we have to resolve the problem some other way, which is quite a fundamental thing, if you think about it. My point here is that to do that properly, we have to reconsider the strong idea that "Fedora is a product that comes out every six months", which is a big job that comes with quite a lot of consequences. It has consequences, for instance, for our most important forms of communication to the wider world: how do we pivot from this simple story that "Fedora is a (set of) product(s) that come(s) out every six months, look out for our big Fedora XX Release Announcements!" to "Fedora is that, but it's ALSO this other thing that has three streams which release every two weeks and roll over according to some completely other schedule"? And so on. I'm not saying these are things that should stop the Change, I'm saying they're things that *need to be considered as part of implementing the Change*, and deciding its schedule. What I'd be worried about is if this Change just amounted to bumping CoreOS up a few hundred pixels on getfedora.org but otherwise changing nothing, because I think that would actually cause some quite fundamental problems in terms of how we think and talk about the thing called "Fedora". It's true that for a while we called Atomic an edition, but it had most of the same issues I talk about above and we didn't really resolve them. I think we sort of got by with that because at that time our communication wasn't quite as strong or clear and Atomic was more obviously a thing which wasn't entirely "baked" yet, so people still didn't consider it "really" a key part of Fedora, it still got handwaved. I think that was us getting lucky, and we really should have addressed more of these concerns more strongly then; I also think it's not a given we'd get away with the same outcome now if we just hung an "Edition" sign on CoreOS now but otherwise didn't consider any of these concerns. > > > > Are any of these silly questions, which would indicate that our release > > process is based on assumptions which need to be fundamentally re- > > examined as part of this Change? > > > > So what defines an Edition ? Good question! getfedora.org uses the concept, but doesn't define it. So the authoritative source, I guess, is still https://fedoraproject.org/wiki/Editions , which says "Fedora Editions are curated sets of packages, guidelines and configuration, and artifacts built from those pieces, that address a specific, targeted use-case. The Editions are the primary Fedora outputs that most Fedora users are encouraged to use and directed towards through the download site." > I think if we don't want to accept a different > philosophy about release schedule and release engineering we can just close > that Change proposal. That's not the outcome I intended, but rather that if we want CoreOS to be an "Edition" but we don't want to require it to conform to the existing "philosophy", as you put it, we need the scope of this Change to include thinking through all the consequences of that and deciding what to do about them. > How do you consider Rawhide for example ? Rawhide isn't an edition, which I think should be clear from the definitions above. Rawhide is sort of the primordial soup from which Editions and all else eventually emerges, I guess. :P > > > > All of this is stuff we could kind of handwave so long as CoreOS wasn't > > an official Edition; we could *more or less* leave the CoreOS team to > > decide what a CoreOS release looked like and when it would happen and > > when it was good enough to ship, and so on. > > > > So this change comes down to Can we have a Fedora Edition that has a > different workflow ? More or less, yes - but with a key addition: "...and if so, how?" -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ 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
