On Wed, 2 Dec 2020 at 21:22, Adam Williamson <adamw...@fedoraproject.org> wrote:
> 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". > Indeed and this was because the current tools and processes were not designed to work with a Fedora releasing every 2 weeks. Being allowed to think outside of the box and doing things differently is IMO a good thing and should be encouraged. > > 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. > And why cannot we make this evolve ? Is it bad to have a Fedora that has streams instead of versions ? Promoting FCOS to an edition is the opportunity to communicate about this and say to the outside, hey we have this new thing in Fedora that has a different model come and check it out. Fedora has the reputation of leading innovation and doing things first, I would like to think that making Fedora CoreOS an edition would match these values. Also having a different model allows us to expand and reach out to other types of users. For years I have heard "I would like to run Fedora on my server, but there is no LTS and I don't want to do a major upgrade every year". Why wouldn't be Fedora CoreOS, a possible answer to that problem ? I believe that we need to be open to doing things differently and welcome different use cases. > > 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. > Is this only a story problem ? I am sorry but I really struggle to understand why we cannot have a Fedora Edition that does not release every 6 months. Would you mind explaining a bit more why it matters so much to be able to say we have a Fedora CoreOS 34 ? > 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. > Considering the use cases and target users of Fedora CoreOS I think telling 2 different stories should not be a problem. IMO this is already happening, I don't think people are confused between for example Fedora Workstation and Fedora CoreOS. I do see much more confusion around Silverblue, IoT and Fedora CoreOS tho. > > 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." > According to the above, it sounds to me that Fedora CoreOS fits the definition. > > > 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. > Happy to do that, is your main concern about communication and the story of what is "Fedora" ? or what are the other consequences ? > > > 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?" > I feel that we already have the how, Fedora CoreOS has been releasing fortnightly for more than a year now. So it is a matter of making more widely known how this is done ? Thanks for sharing your concerns, I think this is a really good conversation to have. > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
