Re: Emerging editions, Fedora 32 Beta, and bureaucracy
On Wed, Mar 18, 2020 at 09:23:13AM -0400, Mohan Boddu wrote: > On Wed, Mar 18, 2020 at 6:38 AM Kamil Paral wrote: > > > > On Tue, Mar 17, 2020 at 10:11 PM Mohan Boddu wrote: > >> > >> Peter and I talked about it a while ago about merging IoT into regular > >> Fedora composes. But we never got to that point. I am not sure whats > >> their plan moving forward. My idea is to merge them together and keep > >> their composes as it is for their testing. > > > > > > Hey Mohan! > > If IoT folks don't reply to this particular issue in a few days, can we > > simply assume merging the composes is the best way forward for everyone and > > just do it? :) I see only benefits. > > This all seems like a communication issue to me, nobody wants to kick the > > ball and move things forward, and everyone else is stalled. > > Thanks! > > I don't think that's the right way to do it, we should let the > community know (esp who are following IoT closely) about what's > happening so that they won't be confused with two IoT related composes > and also let them know which one to follow for what use cases. Hi Mohan, a FESCo ticket sounds like the way to go. To echo what Miro said elsewhere in the thread, this will have to come from somebody who knows the details — so either you or someone else from the RelEng side, but preferably somebody from the IOT side. FESCo simply doesn't have enough knowledge to judge what and when needs to be done. I think we'll be happy to reach out to QE and other people to coordinate further work and then rubber-stamp the proposal. The role of FESCo in this case is not to make any important decision, but it is to act as place where people get notified and a written record is made. Zbyszek ___ 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
Re: Emerging editions, Fedora 32 Beta, and bureaucracy
On Wed, Mar 18, 2020 at 6:38 AM Kamil Paral wrote: > > On Tue, Mar 17, 2020 at 10:11 PM Mohan Boddu wrote: >> >> Peter and I talked about it a while ago about merging IoT into regular >> Fedora composes. But we never got to that point. I am not sure whats >> their plan moving forward. My idea is to merge them together and keep >> their composes as it is for their testing. > > > Hey Mohan! > If IoT folks don't reply to this particular issue in a few days, can we > simply assume merging the composes is the best way forward for everyone and > just do it? :) I see only benefits. > This all seems like a communication issue to me, nobody wants to kick the > ball and move things forward, and everyone else is stalled. > Thanks! I don't think that's the right way to do it, we should let the community know (esp who are following IoT closely) about what's happening so that they won't be confused with two IoT related composes and also let them know which one to follow for what use cases. But if it comes to that, I would need the permission from FESCo to do so and an announcement sent out that we merging them. FYI, my job is very simple to merge them, just add https://pagure.io/fedora-iot/pungi-iot/blob/master/f/fedora-iot.conf#_209-339 to the nightly pungi config and need to change some sync scripts to add IoT variant. > > ___ > 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
Re: Emerging editions, Fedora 32 Beta, and bureaucracy
On Tue, Mar 17, 2020 at 10:11 PM Mohan Boddu wrote: > Peter and I talked about it a while ago about merging IoT into regular > Fedora composes. But we never got to that point. I am not sure whats > their plan moving forward. My idea is to merge them together and keep > their composes as it is for their testing. > Hey Mohan! If IoT folks don't reply to this particular issue in a few days, can we simply assume merging the composes is the best way forward for everyone and just do it? :) I see only benefits. This all seems like a communication issue to me, nobody wants to kick the ball and move things forward, and everyone else is stalled. Thanks! ___ 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
Re: Emerging editions, Fedora 32 Beta, and bureaucracy
On 18. 03. 20 0:31, Adam Williamson wrote: The idea that IoT and/or CoreOS would be release-blocking editions (for Fedora 30, initially, then 31, now 32...) has been - at least, this is my experience and my memory - sort of floating around for months/years, but aside from that one fairly rough document on the IoT doc space, when I went looking I couldn't really find any indication that anyone (FESCo, the Council, FPL, FPGM, anyone) had done anything formal - a ticket, a Change, a wiki page, a mailing list mail, really anything - that said "this is a goal and this is what we think the process of getting there looks like". There was just no process there at all. Maybe I missed it, I dunno. But that's the sort of thing I'm missing. That's not something the IoT or CoreOS teams can really bootstrap, that doesn't really work, because they're not sitting in the right place to have an*overview* of the whole thing from the position of "Fedora the project", they don't have the right levers to pull and it's not their job to do that. They can*say they want it to happen*, but if we just leave it up to the individual teams to make it happen...somehow?...it's not really going to work, IMHO. I get your point better now. However I think that the teams behind those editions should start by *saing they want it to happen* and than we can have a discussion trough FESCo, Council, Program Manager, FPL about how do we make that happen. Yet again, I don't see FESCo starting the thing by saying they want to make it happen.S ure, there might be a FESCo member who cares about this and starts the discussion at FESCo level, or even somebody who cares can run for FESCo (looking at you), but otherwise I don't really see FESCo initiating this. Council? Maybe. FPL? Sure. (But that's my impression about the bodies/positions, maybe it's just biased on how things happen now.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Emerging editions, Fedora 32 Beta, and bureaucracy
On Tue, Mar 17, 2020 at 7:32 PM Adam Williamson wrote: > > The trigger for this line of thinking was this comment I ran across > this morning: > > https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1166100-fedora-32-beta-released-with-earlyoom-by-default-gnome-3-36-desktop?p=1166101#post1166101 > > Put yourself in that person's shoes - just a regular community > enthusiast who's interested in Fedora. They're reading the news sites > (doesn't have to be Phoronix, could be anywhere). They see a story that > Fedora 32 Beta is out. As you can see from that comment, we've done > enough public communication about them that this person is aware that > 'Silverblue' and 'CoreOS' are Fedora Things that are kind of important. > That's why they're expecting them to be a part of a Fedora 32 Beta > release announcement. But, what do they find? Nothing! The announcement > doesn't mention them, the download page doesn't mention them, nothing > in the story we're telling around the Beta references them at all. It > means we're not telling people a coherent story about what Fedora is > and where it's going. That in turn will damage their confidence in > 'Fedora' as a whole, even if they try a bit of the beta that *is* there > and find it works great. It's still going to be in their head that we > don't seem to have our story as to where we're going completely > straightened out. That's not a problem of the IoT team or the CoreOS > team or the Silverblue team, it's a *Fedora* problem, which is why it > needs a 'Fedora' body or person to care about it. I don't think it'd be acceptable to consider those variants as important if they can't be aligned to our development milestones. In general, I *expect* that *every* deliverable that comes from the Fedora Linux collection of software should be present and marketed at each development milestone, *including* the final release. It's either that or allow *all* variants of desynchronize, and I think that's probably not a good idea. Desynchronizing the lifecycle of all the variants makes life much more difficult for users, developers, and testers (basically everyone!) because it becomes far less predictable to figure out what "makes up" a Fedora release. I know that Fedora CoreOS and IoT Edition want to try to de-emphasize the Fedora release they're based on (be more rolling and whatnot), but I'm not sure that's a good idea for marketing/visibility and contribution cognition reasons. As it stands, I have a hard time figuring out what's going on with both of these variants because they don't make it obvious what they're working from, what their plans are, and where they're going. That said, I think it's fine for these variants to "end" earlier and have users seamlessly switch to the next release. The way those variants work mean that this is (hopefully) less painful to do. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
Re: Emerging editions, Fedora 32 Beta, and bureaucracy
On Tue, 2020-03-17 at 22:24 +0100, Miro Hrončok wrote: > On 17. 03. 20 19:01, Adam Williamson wrote: > > Some specific ideas: FESCo and/or the Council should be taking a > > stronger lead here. > > What is your idea of FESCo stronger lead here? > > I just want to say that for the past year at FESCo, I got a strong impression > that we heavily really on what Fedora Projects member do. We rubber stamp > decisions, we do hard decisions ourselves, we approve and reject things. We > firefight problems. However there always needs to be somebody who is driving > an > effort. Sure, several FESCo members are driving several distro-wide efforts, > however I don't really see myself (for example) to drive Fedora 32 Beta > CoreOS. > > Thank you for bringing this topic up. I'm not talking about driving the details of technical work on the project; there's no need for that, that's what the people in the project teams do *already*. It's *other* stuff, stuff that *isn't* just 'how do we build Fedora IoT' or 'how do we build Fedora CoreOS'. Let's go back to Fedora.next again. What was the core of the Fedora.next effort? It wasn't about making specific decisions about what apps would go into Workstation or how exactly the role system in Server would work. It was about defining "this is the scope of what we're trying to achieve here", "these are the Editions we're going to have", "this is what an Edition *is*", "this is what the end point of the overall Fedora.next effort looks like", "this is the path we're going to take to get there", and about then monitoring that process, and about communicating that cohesively, coherently and repeatedly. It's doing stuff like "hey, Fedora 21 release is coming up, are all the editions on track? What do we actually expect of them at that point, and are they all there or thereabouts? If not, what isn't done, and let's poke them to get it done and then keep track of whether it gets done". That kinda stuff. The idea that IoT and/or CoreOS would be release-blocking editions (for Fedora 30, initially, then 31, now 32...) has been - at least, this is my experience and my memory - sort of floating around for months/years, but aside from that one fairly rough document on the IoT doc space, when I went looking I couldn't really find any indication that anyone (FESCo, the Council, FPL, FPGM, anyone) had done anything formal - a ticket, a Change, a wiki page, a mailing list mail, really anything - that said "this is a goal and this is what we think the process of getting there looks like". There was just no process there at all. Maybe I missed it, I dunno. But that's the sort of thing I'm missing. That's not something the IoT or CoreOS teams can really bootstrap, that doesn't really work, because they're not sitting in the right place to have an *overview* of the whole thing from the position of "Fedora the project", they don't have the right levers to pull and it's not their job to do that. They can *say they want it to happen*, but if we just leave it up to the individual teams to make it happen...somehow?...it's not really going to work, IMHO. The trigger for this line of thinking was this comment I ran across this morning: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1166100-fedora-32-beta-released-with-earlyoom-by-default-gnome-3-36-desktop?p=1166101#post1166101 Put yourself in that person's shoes - just a regular community enthusiast who's interested in Fedora. They're reading the news sites (doesn't have to be Phoronix, could be anywhere). They see a story that Fedora 32 Beta is out. As you can see from that comment, we've done enough public communication about them that this person is aware that 'Silverblue' and 'CoreOS' are Fedora Things that are kind of important. That's why they're expecting them to be a part of a Fedora 32 Beta release announcement. But, what do they find? Nothing! The announcement doesn't mention them, the download page doesn't mention them, nothing in the story we're telling around the Beta references them at all. It means we're not telling people a coherent story about what Fedora is and where it's going. That in turn will damage their confidence in 'Fedora' as a whole, even if they try a bit of the beta that *is* there and find it works great. It's still going to be in their head that we don't seem to have our story as to where we're going completely straightened out. That's not a problem of the IoT team or the CoreOS team or the Silverblue team, it's a *Fedora* problem, which is why it needs a 'Fedora' body or person to care about it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://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:
Re: Emerging editions, Fedora 32 Beta, and bureaucracy
On 17. 03. 20 19:01, Adam Williamson wrote: Some specific ideas: FESCo and/or the Council should be taking a stronger lead here. What is your idea of FESCo stronger lead here? I just want to say that for the past year at FESCo, I got a strong impression that we heavily really on what Fedora Projects member do. We rubber stamp decisions, we do hard decisions ourselves, we approve and reject things. We firefight problems. However there always needs to be somebody who is driving an effort. Sure, several FESCo members are driving several distro-wide efforts, however I don't really see myself (for example) to drive Fedora 32 Beta CoreOS. Thank you for bringing this topic up. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Emerging editions, Fedora 32 Beta, and bureaucracy
Thanks Adam for bringing this up, I don't want to give big explanations on the topics, but I just want to mention a few things here: On Tue, Mar 17, 2020 at 2:01 PM Adam Williamson wrote: > > So, today is the Fedora 32 Beta release date. If you examine the > release announcement: > > https://fedoramagazine.org/announcing-the-release-of-fedora-32-beta/ > > and the current state of the download site: > > https://getfedora.org/ > > there are three fairly significant things entirely missing. Those three > things are the things that getfedora.org calls our 'Emerging Fedora > Editions' - the things that are allegedly the 'future of Fedora': IoT, > CoreOS and Silverblue. > > This is approximately how I currently understand things regarding those > editions: > > 1) Silverblue - this is kind of the simplest. Silverblue is built as > part of the regular Fedora composes. Silverblue image builds failed in > the actual Beta compose, which was unfortunate but not release-blocking > as SB is not yet tagged release-blocking, so the Beta we signed off has > no SB images. At the go/no-go and readiness meetings, IIRC, we agreed a > rough plan that we would nominate images from a nightly compose built > after the packages in Beta had been pushed stable to release alongside > the Beta. > https://kojipkgs.fedoraproject.org/compose/branched/Fedora-32-20200314.n.0/compose/Silverblue/ > should work fine for that purpose, but it seems not everything > necessary to actually get that plan implemented has happened, at least > not yet - I see no mention of this in the release announcement or on > getfedora.org . I uploaded the Silverblue nigthly to https://dl.fedoraproject.org/pub/alt/unofficial/releases/32/test/ where we store our "unofficial" releases. But that doesn't mean its pointed on getfedora.org, someone has to manually update it in websites and we have currently 0 resources working on websites. relrod is just helping us out on that. > > 2) IoT - as I've been trying to annoy people about for a few weeks now, > IoT is not built as part of our main 'Fedora' composes: > https://pagure.io/fedora-iot/issue/24 > this is a significant difference from just about everything else in > Fedora. We have several of these kinda 'variant' composes, but the > others are only used to do nightly builds of specific images for stable > releases *after* the release happens. For Rawhide and Branched > releases, those images are built in the main 'Fedora' compose. IoT is > the first and only thing (aside from CoreOS...which we'll get to in a > minute) which is being built outside of the 'Fedora' compose for > Branched and Rawhide. This means we don't have IoT images in the Beta > compose or indeed in any of the main Fedora 32 Branched composes and it > falls effectively entirely outside the existing processes for testing > and releasing stuff. That wouldn't be a problem if IoT were some > unimportant thing we didn't care about, but that doesn't seem to be the > case. It also wouldn't be a problem if this had all been figured out > ahead of time and a plan had been put in place for how exactly we were > going to validate and ship IoT releases, but that doesn't seem to have > been the case either. I keep filing tickets and bugging people and > there have been some back channel discussions and things, and a few of > us as individuals are making up a validation process as we go along as > best as we can, but there doesn't seem to be anything on paper aside > from > https://docs.fedoraproject.org/en-US/iot/edition-promotion/ , which > doesn't really address QA and release process stuff much and seems to > be rather old. As far as F32 Beta goes, again we roughly decided at > Go/No-Go and readiness to identify a specific compose that 'matched' > Beta and ship the bits from that - > https://kojipkgs.fedoraproject.org/compose/iot/Fedora-IoT-32-20200314.0/compose/IoT/ > would seem to fit the bill, and pwhalen has done validation testing on > it at > https://fedoraproject.org/wiki/User:Pwhalen/QA/IoT/Fedora-IoT-32-20200314.0 , > but again this plan doesn't seem to have got as far as getfedora.org or > the Beta release announcement. Peter and I talked about it a while ago about merging IoT into regular Fedora composes. But we never got to that point. I am not sure whats their plan moving forward. My idea is to merge them together and keep their composes as it is for their testing. > > 3) CoreOS - CoreOS is just a *whole* other thing. It is not built like > the rest of Fedora at all. It's not built as Pungi composes, whatever > compose process it does have doesn't run alongside our other compose > processes or output to the same locations, it's like a whole other > product. It also doesn't seem to be terribly well documented (I can't > find any detail on the wiki, docs sites, or any of the git repos I > happen to know of) or even introspectable - for instance, ISO locations > look like >
Re: Emerging editions, Fedora 32 Beta, and bureaucracy
On 3/17/20 2:01 PM, Adam Williamson wrote: Hey Adam, > > 3) CoreOS - CoreOS is just a *whole* other thing. It is not built like > the rest of Fedora at all. It's not built as Pungi composes, whatever > compose process it does have doesn't run alongside our other compose > processes or output to the same locations, it's like a whole other > product. It also doesn't seem to be terribly well documented (I can't > find any detail on the wiki, docs sites, or any of the git repos I > happen to know of) or even introspectable - for instance, ISO locations > look like > https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/31.20200223.3.0/x86_64/fedora-coreos-31.20200223.3.0-live.x86_64.iso > , but if you try and browse around that tree by visiting URLs like > https://builds.coreos.fedoraproject.org/prod/streams/ , you just > get 'Access Denied'. So if the process appears to have broken down and > some poor monkey like me is left trying to help people figure out where > they can get a 'Fedora CoreOS 32' image to try - it isn't very easy. > Right now I simply have no clue if there is something you could > reasonably call 'Fedora CoreOS 32 Beta' or a decent analogue of it. You have reasonable points here. I do agree that the current state of integration between Fedora CoreOS and the rest of Fedora is not quite complete. Part of the reason for this is that we've been working hard on building Fedora CoreOS from the ground up and getting it out the door. There are two things here worth being explicit about: 1. Fedora CoreOS is today not composed by pungi on Fedora infra. It is composed using coreos-assembler[1] in CentOS CI. I think this fundamental difference is the root to a lot of the mystery here surrounding FCOS. People integrated into Fedora processes are familiar with pungi and how it works. OTOH, I'm sure not many of us are familiar with coreos-assembler. 2. Fedora CoreOS follows a rolling release model, where by design, we don't want people to care about whether they're on f31 or f32 (at least in principle). For FCOS, the f32 update just goes out like any other update when we're ready to do the cutover. Thus, sentences like "Fedora CoreOS 32" don't have quite the same meaning as for e.g. Workstation or Server. That said, Fedora CoreOS does have more streams than just stable and testing, and one of those streams should be $((N+1))-based. So we definitely could have some marketing/banners/whatever to point people at. Right now there is not yet a F32 based coreos, but there will be soon as part of our `next` stream [2]. That said, we know there is work to do to make things better understood and more predictable from the rest of Fedora's point of view. Note that there was a lot of hard work to integrate and participate in more Fedora processes as Fedora Atomic Host matured. Know that this work will come as we finish building out the more foundational pieces of Fedora CoreOS. We have opened a discussion ticket [3] for this in our issue tracker, which is where our meeting topics get sourced from and our discussions generally take place. [1] https://github.com/coreos/coreos-assembler [2] https://github.com/coreos/fedora-coreos-tracker/issues/283 [3] https://github.com/coreos/fedora-coreos-tracker/issues/426. ___ 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
Re: Emerging editions, Fedora 32 Beta, and bureaucracy
On Tue, Mar 17, 2020 at 2:01 PM Adam Williamson wrote: > > (many, many words. All of which are reasonable) > I, too, have been a little frustrated with the state of Silverblue and CoreOS. It's not clear to me how much they're supposed to be a part of the normal Fedora release process and how much they exist in their own world because of the different nature of the distribution model. To be clear, I don't blame those teams for this, I have been content the last 21 months to make that Future Ben's problem. Oh look, Future Ben has entered the chat. :-) For IoT, I can't make that claim because I show up in their meetings most week to pester Peter about things. But even then, I've generally been more reactive than proactive because it's also a different beast (in some similar and also different ways). I know Adam is not looking to single out anyone for blame, but I am stepping forward to claim my share. In my experience, things that happen rarely in Fedora can fall into one of two buckets: 1. Subject to an over-engineered policy that will never be tested in any great depth 2. Have a loose, hand-wavy policy that proves entirely insufficient This is clearly an instance of the second bucket. Fedora.next was a great model, but we didn't carry it forward. That may be in part because we've had two (three?) changes of Program Manager since it became a thing and knowledge was lost in the multiple transfers. Independently of this issue, I've been slowly working to improve the documentation so that my successor will not have to count on me to remember to tell them things. But to the matter at hand, as we discussed in the Release Readiness meeting last week, I will review the historical documentation and see what I can do to improve the bureaucracy. It may be too late to do much about the existing emerging editions beyond reacting to the gaps as we find them, but we can at least make it better for the next round. I won't say any more now because I have nothing useful to contribute yet. I would love to see the discussion continue on this over the next few weeks. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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
Emerging editions, Fedora 32 Beta, and bureaucracy
So, today is the Fedora 32 Beta release date. If you examine the release announcement: https://fedoramagazine.org/announcing-the-release-of-fedora-32-beta/ and the current state of the download site: https://getfedora.org/ there are three fairly significant things entirely missing. Those three things are the things that getfedora.org calls our 'Emerging Fedora Editions' - the things that are allegedly the 'future of Fedora': IoT, CoreOS and Silverblue. This is approximately how I currently understand things regarding those editions: 1) Silverblue - this is kind of the simplest. Silverblue is built as part of the regular Fedora composes. Silverblue image builds failed in the actual Beta compose, which was unfortunate but not release-blocking as SB is not yet tagged release-blocking, so the Beta we signed off has no SB images. At the go/no-go and readiness meetings, IIRC, we agreed a rough plan that we would nominate images from a nightly compose built after the packages in Beta had been pushed stable to release alongside the Beta. https://kojipkgs.fedoraproject.org/compose/branched/Fedora-32-20200314.n.0/compose/Silverblue/ should work fine for that purpose, but it seems not everything necessary to actually get that plan implemented has happened, at least not yet - I see no mention of this in the release announcement or on getfedora.org . 2) IoT - as I've been trying to annoy people about for a few weeks now, IoT is not built as part of our main 'Fedora' composes: https://pagure.io/fedora-iot/issue/24 this is a significant difference from just about everything else in Fedora. We have several of these kinda 'variant' composes, but the others are only used to do nightly builds of specific images for stable releases *after* the release happens. For Rawhide and Branched releases, those images are built in the main 'Fedora' compose. IoT is the first and only thing (aside from CoreOS...which we'll get to in a minute) which is being built outside of the 'Fedora' compose for Branched and Rawhide. This means we don't have IoT images in the Beta compose or indeed in any of the main Fedora 32 Branched composes and it falls effectively entirely outside the existing processes for testing and releasing stuff. That wouldn't be a problem if IoT were some unimportant thing we didn't care about, but that doesn't seem to be the case. It also wouldn't be a problem if this had all been figured out ahead of time and a plan had been put in place for how exactly we were going to validate and ship IoT releases, but that doesn't seem to have been the case either. I keep filing tickets and bugging people and there have been some back channel discussions and things, and a few of us as individuals are making up a validation process as we go along as best as we can, but there doesn't seem to be anything on paper aside from https://docs.fedoraproject.org/en-US/iot/edition-promotion/ , which doesn't really address QA and release process stuff much and seems to be rather old. As far as F32 Beta goes, again we roughly decided at Go/No-Go and readiness to identify a specific compose that 'matched' Beta and ship the bits from that - https://kojipkgs.fedoraproject.org/compose/iot/Fedora-IoT-32-20200314.0/compose/IoT/ would seem to fit the bill, and pwhalen has done validation testing on it at https://fedoraproject.org/wiki/User:Pwhalen/QA/IoT/Fedora-IoT-32-20200314.0 , but again this plan doesn't seem to have got as far as getfedora.org or the Beta release announcement. 3) CoreOS - CoreOS is just a *whole* other thing. It is not built like the rest of Fedora at all. It's not built as Pungi composes, whatever compose process it does have doesn't run alongside our other compose processes or output to the same locations, it's like a whole other product. It also doesn't seem to be terribly well documented (I can't find any detail on the wiki, docs sites, or any of the git repos I happen to know of) or even introspectable - for instance, ISO locations look like https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/31.20200223.3.0/x86_64/fedora-coreos-31.20200223.3.0-live.x86_64.iso , but if you try and browse around that tree by visiting URLs like https://builds.coreos.fedoraproject.org/prod/streams/ , you just get 'Access Denied'. So if the process appears to have broken down and some poor monkey like me is left trying to help people figure out where they can get a 'Fedora CoreOS 32' image to try - it isn't very easy. Right now I simply have no clue if there is something you could reasonably call 'Fedora CoreOS 32 Beta' or a decent analogue of it. So, in practical terms for Fedora 32 Beta: it would be good if we could complete the plan of identifying SB and IoT nightly images to place alongside the Beta release, and update getfedora.org (and maybe the Beta release announcement) to refer to these. For CoreOS, it would be good if we could...I don't know...do something? To call something 'Fedora CoreOS 32 Beta' and let people
