 So yeah, I was told, please provide me your slides and that will integrate them into the rest of the deck. So I chose to not have a title and then on top of that I have a mishmash, I can't even talk, of like formats going through. So it should look awesome. So I'm Langdon White. I've been the modularity objective lead for quite some time now. I think rings are trash as if you've seen my older talks, you'll know why. And I think modularity is much better. So this is a little bit of an objective update. Unfortunately, I don't have lots and lots of bullets because that would require me to like write bullets. So instead I have fun pictures. So Fedora 27 with modularity, we were so close. We really were. And I would disagree with Gallagher from earlier. I still have hope. And so we have, as you may have seen before, the modularity Lego kind of theme going on. So we've got a nice little Jago character there in the guy's eye or Gal's eye, I don't know. So we tried really, really hard to basically do a fully modular OS that we could ship like essentially a minimal set for Fedora server for a number of reasons, but partially, like mostly wrapped around maintaining it. We decided not to. So the maintainership side of it is it was as difficult if not more so to maintain the core component modules as the entire distro. And so until we find ways to improve that experience, it's just, it just wasn't something we could ship. That combined with the humans involved in maintainership, we kind of didn't really realize how much they would have to be integrated immediately into the modularity effort in order for us to maintain this set of base modules. And so as a result, they would kind of have to, we had always wanted it to be kind of an opt-in feeling, but we kind of would have to opt in that was like 200 people or something immediately. And we thought that probably wasn't gonna fly very well. So that was why we decided to back off on Fedora 27. Then moving on, then we decided, hey, why don't we blow the whole thing up and redo it differently? So in the simplest case, what we decided to do was essentially cheat at the platform level and declare existing RPMs as if they were the core of the, and now I'm gonna, yeah, right. No, I was gonna collide on CoreOS actually. But so the core component and call it the platform module is what we were calling it originally, but just treat traditional Fedora as that module. So in theory and the incredibly short blog post that Stephen Gallagher wrote about it, this sounds really easy and there's a nice picture here that makes it look really easy. And oh my God, it ran into a bunch of problems that we didn't anticipate because the architecture changed in the middle and so that was fun. But, but we did finally ship it and it works. In Fedora 28, that one over there is my daughter, that kid I don't know. These guys, you know who they are. So we managed to ship it. It wasn't everything we hoped and dreamed, but it does in server, you know, works well with DNF. You can have multiple versions of things. It actually was kind of mind blowing. Literally, I think it was like a week or two before we released, I was trying to get a piece of software to run, it needed Node.js 6. We only had Node.js 8 in F28. And so I used a module for Node.js 6 and it just worked. It was crazy. But we still needed all these changes in libDNF so that all the other package managers that kind of, you know, are used in various places in Fedora would inherit basically knowledge of modularity. That took a while. However, I think it's in raw hide and working officially now. Yeah, mostly. So, but the goal is to have that ironed out, you know, as soon as possible. It landed two weeks ago and no one has complained yet, so I'm gonna go with it. All right, so it landed two weeks ago and no one has complained, although I have seen some complaints, so yeah. Grain of salt. I'd like someone to use it. Exactly, exactly. If someone's complaining that means they're using it, which is always good. So then finally, I just kind of wanted to talk about, and this is kind of where we're going. So there's currently a Fedora change. This one's terrible, I agree. I couldn't, who takes a picture of a thing with black edges on a black background? I mean, really. But it was best like. I don't know if it's water on my hand or if the boss would be anymore. All the edges are black, whatever. I'm very annoyed with the random people on the internet who I steal their work. But there are attributions, it's all fair use, you know, whatever. But so what I want to talk about here was, you know, modules for everyone is the name of the change for F30. And the idea basically that we will have modules in all the editions and available in containers, et cetera, in the package managers that are appropriate to those environments. Sorry? That's 29 out of 30. Oh, 20. Wait. One. 29. 29. Yeah, so I have a mental block about what version we're on and which one's next. I always mess it up. So the next version, whatever that is. So that's modules for, oh, I even wrote F29 in my notes. So I have notes. So modules for everyone, that's the idea. However, the big thing is we need more modules. You know, Matt alluded to it earlier. We need people creating them. We also need to improve our tooling such that it can be essentially a non-event to create a module, which we're very close on, but we have to kind of, you know, kind of improve that kind of documentation and getting it out there and that kind of stuff. But it's mostly in place. Let's see, what else? Oh, and then we also want to make sure that we get a stronger integration with modules leading to various container technologies. So that might be snaps, it might be flat packs, it might be, you know, we don't say, you know, whatever, podman containers now, or build-it containers. Yeah, cryo is, yeah, whatever. Yeah, OCI images, there you go. That's a good non, that's a good PC way to put it. So, yeah, but I reinforce we need more modules. Really hope the community can start participating and find it useful. But I highly recommend trying out being able to use two different versions of something. It's really, really handy. Then the last thing I wanted to talk about was just kind of the talks that we'll be covering during Flock about these subjects. Modularity also will touch some other talks and if I missed it, direct one, I apologize. But there's the talk later today that Matt also talked about already, that is Paul Frield and somebody, I can't remember who. And somebody else with Paul, oh, and Josh, we'll be giving, that's kind of talking about life cycle and why it's interesting and why, you know, in modularity is a big part of that. And then the too fast, too slow, so this is Stephen and I kind of talking about when does a module make sense and when might it not. And so we have a bunch of use cases where we kind of say, you know, this is a good idea for this reason and how to do that. And then after that, I actually am doing a talk about what other distributions are doing to solve this same problem. Because over the last whatever number of years we've been working on this, other distributions have noticed the same problem and have started to have other solutions. For example, Amazon Linux 2 is a good example. Then that's my talk and then the modularity restrain. This is Stephen Gallagher again and Mohan talking about how the modules get built and how that whole pipeline works. And then the State of Fedora server edition and talking about where the future of the server is and it's tight integration with modularity. So please come to that for ideas. And then finally we're gonna do a help desk style, you know, kind of workshop where if you wanna come and build a module or you're not sure how to or whatever you can come in and ask us. And I will be there but I won't really be the expert. It'll be like intelligent people. So yeah, but so those are all of them. And I think that's my shtick. Thank you. Our next speaker is going to be Steph Wolters. Sorry, I apologize for that. Wait, you're not allowed to have slides either apparently. Oh wait, are you this one? Yeah. So I have mispronounced Steph's name and I wanna apologize for that. He is Steph Wolter. Because it means Colin Quid. Yeah, yes. Say Walters. Is Colin here? No. All right, he's now Colin Wolter too. This way I don't have to learn which one has the s. Do you want this mic or do you want this mic? That mic looks good. All right, this mic is totally awesome. Please welcome Steph. He's gonna talk to us about continuous integration. So Dominic was good. Yeah, he's gonna go to the other screen for stupid reasons. You don't have to find the mouse. I was too busy with the s. There we are. You can use the mouse to just be returnable. There we go. Look at the mouse, there you go. And now we click the thing. Can I hit share button? No. Make it happen. Oh. Just, there we go. I'm gonna act by accident. Woot! All right, so Dominic is actually the objective lead and I am not Dominic. Dominic couldn't make it. But I'm happy to update you on how Fedora CI is looking. This is something that was started around the time of last flock. And the intent was, we started with atomic host, but we expanded beyond that, was to make sure that changes in Fedora land when they're functional, not just when they're packaged. We prevent the non-functional changes from landing so that they don't break other people's development work, users of Fedora, and so on. And this is known as continuous integration. Basically, integrating the thing together, making sure that it's tested, the whole thing is coherent, and doing that for every single change. So, a bunch of pieces are there and working. One of the biggest fundamental changes that you would have noticed is that instead of just defining what goes into Fedora in diskit, we started defining how it works. And that is the tests directory You can see this in so many of the packages that are in Fedora now. And these are tests from all over the place, wrapped in a standard specification, kind of like we take tar balls from all over the place, wrap them in spec files, and, you know, by hook or by crook, bring them into a consistent packaging format. Similar effort. And that's been going on. In addition, the pipeline to run the tests has been running. It's been running against Fedora 27, Fedora 28, Tommy Coast. Results are being stored in ResultsDB. There's a engine called GreenWave that has policy for gating on those tests. And there's code in Bode that allows gating. So, on the other side, we also wanted to modernize the workflow, because it turns out people nowadays use pull requests, use proposed changes, use code review, and we were not doing that in diskit. So, this is something that was started as well. Many of you were involved in. Pingu couldn't make it this time to flock, but he's been someone who's been heralding this. And there's Pagar on diskit. Source, src.fadorproject.org. It's not just a theoretical thing. It's not just a prototype. People are actually using it. And this is what's really cool. There's 4,500 pull requests that have been filed. And no, most of them have been merged and closed. They're not just standing there. And before you ask, were those all automated? Were those all scripts? Or were there just a few people? Well, it turns out some of them were automated open. But if you look at those very carefully, I know that the Python project, renaming a bunch of packages, posted a ton of pull requests. If you look at those, you'll see that many of them are opened by someone, reviewed and merged by someone else. And that's exactly what we wanna see. So that's cool. In addition, 250 diskit repos have used more than two pull requests. So you can look at that 4,500 and if you're thinking, oh, most all of those are from such a mass effort? No, that's not the case. 250 different project, different repos, have used more than two pull requests. Or two pull requests or more, actually, that's wrong there. And so that's actually showing that code reviews starting, people are actually using this and that change in the way we do development, the way we collaborate on stuff, rather than having a single king of a repository or a package, the maintainer, we're actually starting to collaborate properly, starting to act more like modern development, like GitHub. And excuse me. The problem is, given all those ingredients, we have tests, we have tests running, we have pull requests, we have a code review going on, we're still in the awkward place where CI is not having an effect. And so Schrodinger's test is a test where no one looks at the results and that test can be said to have neither passed nor failed until someone takes a look, until it has an effect, until it has an action. And I have pointed my finger at various CI efforts and said, hey, this is a problem. Well, it turns out this is happening pretty close to home, so awkward. And we need to close that gap. In order for the Fedora CI objective to meet its goals, this needs to be done. And let's see what that would take. So there is assembly still required. We have pieces that are really working individually, great, but they're not working together. We tried around last flock, was a time when the gating was going to be enabled, then it got delayed due to various deadlines. It was enabled for packages that opted in for quite a few months, like four months until April. What does gating mean in this case? It means that a package that has broken or failing tests does not get to merge something through Bodhi. It does not get to have its update go into the compose via Bodhi. So in April, the gating policy was disabled. Well, actually the gating mechanics are still there, but all the policy was removed for any, not just for tests and disk it, but for other stuff too, so that gating is pretty much off. It's not enforced in Bodhi. So workflows were being interrupted. It was a good point. There was some usability issues, particularly around waving of false positives. So this is not, this is not, it was terrible. It was terrible, exactly. And since April, so that's four months. By the time this is fixed, it'll probably be up five or six months to fix that terrible UX. And people in this community here and someone who are not, someone who couldn't make it, how am I working on fixing that? So apparently it takes some time to make that change. In the meantime though, the tests that are there are having no effect and the tests are bit rotting because as you change the package, the test is not enforced to be updated for a given behavioral change or something like that. It gets out of sync and eventually you have most of the tests in a rotten state. So this is not a good place to be and something that we need to fix. So what do we need to happen? Well, there are Bodhi fixes for this UI change, for the UI fix, they have been coded and they are in staging. They need to be deployed. The gating policy needs to be enabled again. And remember all those 4,500 cool pull requests that are using code review, that are having multiple contributors to a change in disk kit. We need to finish doing the work to actually do testing on those pull requests, tie the test results back to the pull requests. This is not theoretical, this is happening in other pegger instances on disk kit. So really it's just deploying the changes here and actually having them take an effect in the Fedora community. So, pitch, Brian Stinson is giving a talk about Fedora CI. He's there, go see this talk about the pipeline, about how it affects the package or maintainer, about the waving, the terrible UI changes that are now being fixed, about all aspects of this and about how Fedora and CentOS are also, this is a great example of Fedora and CentOS working together. So, make sure to go to that talk. All right, that's it. Thank you very much. Next up is going to be Peter Robinson whose slides we hope have collapsed into a single quantum state. Probably not. They're finished. I suddenly thought of some changes I wanted to make, it's too late now, right? Yeah. Do you use, which of the 700 standards of video connector? I can't pull that out. I think I can use that one. All right. Except it pulls to places. This is yours. You're never getting that power cord back. It's a community effort. Seriously, that's your password? I am disappointed. You need more entropy. I know it's a great wallpaper but a single-letter password, that's just unreal. Well, I understand he runs it like an IoT device. Yeah, exactly, 26 tries, all right. And no computer can work that fast. So, I'd like to introduce Peter Robinson talking to us about IoT, maybe? Yes, okay, IoT. Do you want this mic or that mic? I think that mic. All right, it's here. I actually have one of these things here. It might even work. Hi, I'm Peter. I'm the Fedora IoT lead for the objective. It may even... Oh! My laptop needs a reboot but I wasn't going to risk it just before. Yeah, you know. Anyway, so this is an update to the one I gave to the council back in February. Valentine's Day, if I remember correctly. No one ever said I wasn't married to the project. So, just quickly, how we fit to the Fedora mission. I don't think I need to go into too much detail. Matt covered this fairly well in his talk. So, yeah, so it's to make Fedora a default place to innovate for IoT and IoT related areas. I realise IoT is a vast swath of a billion different ideas out there. And so, and most people that know me realise I have more fingers than I have in more pies than I could eat. So, for the first time in a long time, I'm actually trying to focus on small bits so that I actually, or we as a community actually achieve stuff. But of course, can't be done by just me even though in a lot of cases, people know that I will try. So, the audience, well, it's many varied wide. So, hopefully and especially in the case of things like the Raspberry Pi, I'm hoping that we can get this into the education thing and I was gonna have a chat with Matt at some point based on his education slide that made it nowhere. There's a bunch of different ideas and a bunch of different initiatives around the place where this is useful. I'm hoping to be able to fix up a bunch of the Raspberry Pi stuff with Tom Spot Callaway in the Fedora 29 release, which makes it much better for the maker space because we'll have hopefully support for cameras and hats and various other bits and pieces which we haven't had up until now. But anyway, IOT gateways, home automation, one of the Fabians has had home assistant up and running on Fedora IOT already. Embedded use cases, there's a bunch of company and people and various organizations that are interested in using it in routers, gateways, switches, storage, all sorts of various other weird and wonderful things that I'd never even thought of. And obviously, one of the interesting things that IOT brings to Fedora, which we've not had in the past so much from different organizations is there's a bunch of companies and partners and various other bits and pieces that are interested in working with us. A lot of my time I spend dealing with enterprise stuff as well and we've had some very interesting meetings with various different and it's amazing the number of organizations that have reached out to me about this. So I'm hoping that'll be a way that we get different organizations than traditional involve more in Fedora. So we have obviously my objective update now. IOT use case, birds of a feather, Thursday afternoon. So if people are interested in various different use cases, interested in working, getting it on road maps and various bits and pieces, come along to that and I'll be directing that. I don't intend on being the only person speaking there. Spot and I are doing Fedora on the Raspberry Pi talk where we've been, where we're going. So if you're interested in the thousand different users for the Raspberry Pi, come along to that and you'll get to see a bunch of the issues that we've had, where we've been, current status and where we're going there and then the IOT Hackface Fest on Saturday morning of which I'm going to be doing up an agenda and I'll publish that. And if you find me in the intervening time, if there's stuff that you're interested in addressing there, come along to that and we'll get added to the agenda. It should be fairly fluid. I have a bunch of devices and a bunch of stuff and a bunch of Fedora features for 29 that I'll be working on and helping people out in various different bits and pieces and of course there's the hallway track because everyone who knows me knows that I like to talk just a little bit about IOT. So a quick technical overview. I've crossed things out. I did cross out I686 although just last week I actually had an official request for this and that made me sad. The company that requested it was requested to actually, if they want it that much they were told that they need to commit resources from the kernel upwards. So we'll see where that request goes. It may be good for the I686 community in general but we'll see. So as I've mentioned in various different places, I was very excited about the CoreOS. Fedora announcement because I think there's a bunch of technologies including their updates platform whenever that gets released as open source that is very exciting from an IOT point of view. A bunch of stuff was covered both by Matt and Dusty and various other people previously so I'm not gonna go into all of it. Multiarch 64-bit x86, 64-bit ARM-V7 is coming really soon. Multiarch container builds in OSBS covered previously looking forward to that in Fedora 29. The plan at the moment is to do monthly releases so similar to the way Atomic was doing two week Atomic releases where probably going to aim for monthly sort of rolling releases and then automatically moving the releases from 28 to 29 to 30 and so on and so forth and as much CI, CD testing as possible primarily because I'm lazy. So we have as Dusty mentioned Fedora 28 nightly releases that we're very much just testing the water and to get stuff out there for people to start to play with. They're pretty static and just rolling along at the moment. F29 is where all the fun is landing. As I mentioned we'll have ARM-V7 shortly. I have a whole bunch of patches and pull requests in process that should by the end of the week have them enabled whether they actually boot or not. We'll be funding games for Mr. Jones and myself to debug. The container tech that we're focusing on is the OCI initiative. We're shipping Podman and NotDocker by default in the images because we want obviously with IOT a lot of small devices. So minimum resource utilization as possible. We'll be moving to the CoreOS bits and focus more on that as they land and I'll be following the CoreOS Fedora upstream merge pretty closely and hopefully as I mentioned so Fedora 29 should be a spin. I'm hoping Fedora 30 will be an official edition with all the CoreOS bits there. At the moment we have a handful of supported devices from Raspberry Pi, the 96 boards, Dragon board 410. There's going to be a number of other devices in Fedora 29. My plan, so all of the Fedora ARM devices and x86 and everything will work and be supported or supportable. My intention with IOT is a little bit and we'll see how this works out. Trying to dangle carrots for vendors to get more actively involved. If they want their device to be officially supported they can come along and help do some of the work. If they don't wish to do any work it won't be official release blocking device. We'll see how that works out. Yes. For the various sort of devices, the Indian board, so the individual boards and the software are all individually designed for hardware. It is one common thing that contains all the drivers. So we're using standard Fedora kernel at the moment. I haven't subjected the kernel team to a custom kernel. And I mean, my intention there is to keep it as generic as possible because the ability like if we, a lot of distributions produce an image per device and in ARM in general we've managed to avoid that to date. And it generally works relatively well and we generally get like, so Raspberry Pi is obviously the most common device in ARM. I expect that to be the case in the IOT ecosystem at least initially. Although there is some fairly cool devices that I'm hoping that we should have details about in Fedora 29 shortly. For some very interesting IOT use cases, the 96 board, it's Ultra 96 with FPGA and things like that, plus some other higher end devices. So we should have more details about them and availability around that shortly. But yeah, the intention is to have single images available and we'll be doing as we get more into it. I've been asked a lot about how we deal with vendor kernels and things like that and that's certainly on the roadmap but obviously I wanna focus on stuff that's purely in Fedora initially so we can get a good experience there before we start to go more into those sort of corner cases and what have you. So. The other thing I wanted to highlight is we had our first Google Summer of Code participant, Christian, who's somewhere here, I hope. Thanks to Dusty and Jonathan for helping the mental side of things because it was very much OS tree focused. We pulled in a host of other people, Peter Jones with Grubb, Leonard for System D Advice, various other atomic core OS, Colin Walters, et cetera, et cetera people. The idea is that you apply an OS update, it goes and runs a series of health checks, checks that it can speak to the update platform, checks that it can get out to the internet if necessary, checks, sensors and various devices that need to be there so if it suddenly can't see critical temperature sensors or something like that, it will automatically initiate a rollback to the previous version. It was obviously IOT focused for GSOC, the project as a whole is generic and can be used in a standard Fedora system or an atomic system, obviously if it's a standard Fedora system, it's gonna be much harder to have a rollback to the complete previous version, but it's generic. Christian managed to touch things from Grubb all the way through System D up through so he's done very, very well and this was very exciting and it should be landing into roll hide really shortly. Community, thanks to the new program manager, we now have an initial version of the PRD and the working group stuff is in progress so I'm very excited about that. We're doing standard Fedora mechanisms, articles, various other evangelism to build out the community, dealing with partners, et cetera and we're starting to actually, the meetings are becoming fairly active with quite a few contributors, even though we've only been sort of had images and stuff around for maybe two months now so I'm very excited about that that I'm not the only one that's doing it all and then we have various communications methods, including a number of bits that flock obviously and that's it. Do you mind leaving your live talk just a little bit on screen for a few minutes? Sure, thank you. So I would like to bring Matthew Miller back up to do some Q and A for us and then I'll tell you about lunch, no pressure, Matthew. Also, for anyone who is speaking anywhere at any time in the world at a conference, always repeat your questions. That's doubly important here because if it doesn't come out of the speakers, it doesn't go in the recording and then you hear things like, yeah, that's a great question. So if you put 47 in the registry, your machine will not explode. Do we have a registry now? Yes, we do. It's terrible. Yeah, I didn't do questions after my talk because I didn't know how efficiently the whole rest of things would go but I am happy to take some now, ask me anything. If I don't know the answer, I will either make something up or redirect you. So, you don't get lunch earlier if you don't have any questions, so. So when you were showing the graphs for new contributors by the meshed-seq graph, I noticed that in fellow athletic reader, like the number of new contributors was huge compared to every other release. And do you have any idea of why that might be? Yeah, so the question is, I'm in the match-stick graph about new contributors by release. There were quite a few in the Fedora 23 timeframe relative to other ones. No, I don't have any particular reason. I don't know why that was so good at bringing things on. See, when was that, I don't know, it was around this time of the first flock. Maybe that kind of helped bring people in. I think some of the Fedora Next stuff was taking off. So I think it goes along with the surge in popularity overall, so I think that might be the easiest explanation. But I haven't dug into that deeply. I think that's a good question. But I don't, I haven't dug into that deeply. All the stuff is from public data, so I'd be really interested in anybody else who wants to try and figure out what makes those things kind of happen and how we can replicate it. Yeah, just. So you talked earlier about possibly doing something like a new way of doing things. Yeah. Yeah, so the question was, I said earlier that it'd be nice to actually have UUIDs and kind of have a better sense of what's going on. And so the question is, why don't we have that already and what's the barrier to doing it? And I think there's kind of two things. One is, I think there's a lot of things that we need to do to make sure that we have a better sense of what's going on. And I think there is kind of two things. One is like everything else, ideas are easy, lining up all the work is actually work and not all of those bits have been connected to do that. We've also had a lot of concern and care in the community for privacy and we want to make sure we do it in a way that respects people's preferences for privacy. We had previously had a thing a long time ago that was an opt-in data collection mechanism and that kind of failed for two reasons. One was the amount of data was so huge that it overwhelmed the programming of that original service and then nobody was able to update it. But also because it was opt-in, we didn't have a really good way of measuring like that versus reality and it seemed from the numbers we were getting that it was kind of skewed in certain ways. So it didn't seem that valuable. So we feel like we kind of need something that is opt-out at least, but with a minimal amount of data, we need to kind of figure out the right balance to all that in a way that respects privacy and is useful. The old opt-in system was a full hardware profile. Which was incredibly useful in the original, but this is a different thing. This is just able to change the way we go. Yeah, so the old opt-in system was a full hardware profile, which is probably, it's pretty hard to make that anonymous because it gets unique very quickly because there's only so much entropy in the world and every little bit cuts it down. But something very minimal we can probably do in a way that respects people's privacy and it's mostly just a matter of doing it at this point. And also figuring out how much information we want to include and still, do we process our architecture or what level do we put into the opt-out data? Steven? The I686. What is the optimum number of bullets to put in the head of I686? Maybe that's a question back for Jeff. It might come down to Bob. Right? What's that? Oh, how many bullets should we put in I686? Yeah, and so that's kind of hard. I mean, you see in this slide there, it's still about 20% of the system's checking in. I haven't broken that down because I would need to make Smooch do it by latest releases, by the way, the data comes into me. I assume that most of that is in older releases and that if we look at current releases, it's much higher on modern architectures, but it still is a good chunk. And the reason we haven't killed it so far is that when we said, it's time for this to die, people said, wait, wait, I'm still using this, I will maintain it. So as long as people are doing that, I think we should keep it alive. If those people actually say, okay, I can't do this anymore, then it's time for it to be gently sunsetted without violence. What, fire? Wow, a lot of hatred for the I686. Mike, in the back of the room. What are we doing to attract more youths? What are we doing to attract more youths? Youths. Youths, young people. Youths, not olds, youngs, childrens, people younger than me. Yeah, right? Not all that much. And that's something that we can do a lot better. And I think, yeah. So I think the education market, the slide I had there is good. Okay, like, I've got it. I'm gonna, you got your hand up there. You wanna answer? Yeah. Here, come take the mic. I'm handing this over to Mindshare here. Yeah. For those that don't know me, I'm Edward Lucena. Now I'm working as representative of the marketing team. And the talk I'm doing in Flock about marketing is especially to avoid that kind of issues that we need to understand the new style of media consumers and try to attract them to the project. One of the ideas we have is to retake the YouTube channel and make it more interactive. There's a lot of people there looking for videos about Fedora and we are now only publishing Flock talks and that is not attractive to new users. The other thing is already done is the podcast and another strategy, I'm going to work with the social media team. It will be to take the Instagram TV to the channel. So that's the main three things we are doing it right now. Edward does the Fedora podcast and it's awesome. All right, so not all that much was a pessimistic view of it. I think there's a lot more we can be doing. I think the student outreach thing is important. Another thing we're experimenting with and I have the discussion section about this, we're experimenting with Discourse which is a web forum platform and I can talk about that and Hyperkitty and some of these other things. I know most of us are very familiar and comfortable with mailing lists. Mailing lists are not the future. They are not the future of open source development. And even though we may be used to them we need new ways to communicate. We need to have a new web presence. I know we had the Fedora Hubs initiative previously and we just weren't able to commit the resources to that to make that really successful. So we need to kind of explore other ways to make a modern web presence for Fedora. So I think that's part of the way we need to do this too. And I think also the IoT initiative is super important for this. When I started with computers it was Apple II's in the classroom hallway and the cool thing about it was there was commercial software that ran on those things and there was also, you booted it up to basic and as a fourth grader with a lot of work but it was within my grasp to make programs that were basically as good as the programs that came on the purchase discs. And so that was pretty like as a kid getting into computers that's powerful. You can look at it and you're like this computer boots up I can tell it what to do, I can make it do these big important things. If you get a computer today it's got software that has billions of person hours into it, if you play a game it's not a thing that you could write yourself it's something that takes a Hollywood production to make. So that makes it the end to making a computer do something that makes you feel powerful is a lot harder with desktop PCs today. So IoT kind of gives that this is not a pun. It's a gateway basically into computing because you can get something like an Arduino or Pi those things and you can make it do cool practical things that you are in full control of. So I think that's an important thing that Fedora really needs to address that will bring in more people who can or into computing and open source in general. Yeah, yeah. Josh is asking me about my optimism slide and why it was so low at the last block. I think we had a lot of things on fire at that time. That's kind of the things that the modularity stuff wasn't going so well. The release we're working on is slipped. I just kind of an energy thing was low. I think, I don't know, maybe some personal burnout that happens. I just came now off of two weeks of vacation and so maybe that's also good from my optimism. But yeah, no, I'm just feeling good. You're allowed vacation. What? You're allowed vacation? I'm allowed vacation, right? I think there were a lot of questions about modularity that you were trying to work that ground for. Yeah, there were a lot of questions that we didn't really have answers. We didn't have a kind of a clear path for them. I think also the CoroS thing is a nice injection of some exciting new people, new ideas, new technology. I think that's really positive. That's a big chunk of my optimism there as well. Is that sufficient? I don't know. Maybe I'm just, yeah, yeah, yeah, that's good. Cool. Anything from like this side of the room? Dennis, do you have any questions? No, yeah, yeah. Can I? This question is from, like, I asked that whether you're tracking the translator. Ben has blown his nose at it in an opportune time and I didn't hear that. Tracking the. Translators. Translators, yes. Are translators tracked in the active contributors? No, translations are one of the things that I'm not counting in that. Are translations giving Fed messages right now? They are. Okay, yeah. So I can track things that generate Fed messages that have a username attached to them. One of the things that is difficult is some of our services are not necessarily only tied to FAS and have other user accounts there and I would need to have some sort of mapping from user ID to FAS in order to track in a meaningful way. So right now I'm not doing that. We can talk about that. Another big thing that I could be tracking that I'm not is Pagger, either the source, like those pull requests or actually Pagger tickets and things like that. That'd be something that'd be easy to add into there. I might need to add some monkeying with the numbers to make it a smooth graph. But yeah, I don't have that. But I just thought of another big thing. Oh yeah. There's a lot of activity, like the core OS stuff is happening on GitHub because that's kind of where they traditionally were and rather not in Pagger. We need to figure out a way to integrate that into my stats counting because otherwise all that's going to not get measured and that would be sad. Patrick, are you solving my problem back there? Yeah, it's a GitHub message. Yeah, okay, so. I've been working for years. Yeah, so there's a GitHub Defend message but we also need to have a GitHub ID to FAS mapping of some sort to make that work properly. So yeah, there's a lot of things not tracking. Translations are one of them. Stuff that's happening outside of the Fedora infrastructure also hard to track. Yeah. So where do you see Fedora project in one year and what are we doing to achieve it? Yeah, so where do I see Fedora project in one year and what are we doing to achieve it? So yeah, hopefully more optimism. I think a lot of these objectives are basically the things we're working on in one year. So I definitely expect to see an IoT edition and a lot more IoT users. Fedora IoT on the front page, you get Fedora. CoreOS will be there replacing Atomic and I hope to see an influx of new users for that. I want to make sure we retain both the existing container Linux community and build that up as kind of a definitive. This is how you want to run containers operating systems. I think that will be a big thing. And yeah, a lot more modules and a lot more connection with CentOS. Those are kind of the things I'd like to see there. And I think what we're doing to get there, all of the stuff that's happening at this conference is kind of advancing those things. I would definitely like to see the line clearly going up again and I'd like to see the contributor numbers wider. All right, you thought of one, Tess. When am I expecting to see the first CoreOS to deliverables and will they be multi-arched from the start? We're expecting to see those basically after the F29 Fedora Atomic host release, the early preliminary deliverables so that should be coming out. I'm looking over there at Benjamin Dusty. And multi-arch. So. You've made Dusty stand up. Yeah, so regarding multi-arch for, I guess, Fedora CoreOS, we have some members of the community that are very interested in making sure that multi-arch is something that we consider from the start. So that's something that we want to do. I will say that if we have to basically choose between releasing anything or releasing with more than one architecture, we will probably will choose to release with just X8664 for Fedora 30. But we really want to make sure that we do consider multiple architectures and that we have it for Fedora 30. So we have some very motivated community members who want to make it happen. We're already delivering multi-arch for Fedora Atomic host, which I mentioned earlier. So we should have it. I just don't want to promise anything there. Does that help? Luca? For all the questions for both of you, is there something like a higher order level of support stuff, but at the same time, the CI doesn't cover everything equally? Right, do we? 64 versus C? Do we essentially want to speak about tiered support for a particular, you know, is 64-bit AMD, you know, prioritized for it? Yeah, so we have this concept of a primary architecture and alternate architectures. Is that the right terminology now? We've changed our terminology around a couple of times. So yeah, we have to be kind of careful about support in general, since officially we don't support capital S anything. It's all kind of community support that depends on who is there and who is interested in making sure that things work and are tested and can help solve problems. So all support is at that level, of course. But for our different deliverables, we have the concept of this is a primary architecture. So for example, for Fedora server, X86, 64, and AR64 are the primary architectures for server. So, and then there are other architectures which are built but are not the primary. So we definitely have that concept. So it would be possible to say that for Fedora Core OS, X86, 64 is the primary architecture and these other ones are available. We don't have anything more fine grained than that, which I think is okay because there's no SLAs for anything anyways. So is that addressing? And Peter definitely wanted to comment that he's very interested in multi-arch for the Core OS technologies because he's so interested in them for IoT where obviously ARM and a lot of different architectures are important. Risk five. So there's a lot of partners in the community not just ARM-based that are interested in various technologies as well. Partners in the community are particularly interested as well. There's some whispering, I don't know. In that case, which is whether something is blocking or not blocking for the release. Right. Yeah, we do it here in that way. Yeah, but that comes down to primary or alternative architecture. Yeah, right. So if it's a primary architecture, it's blocking to release. If it's an alternative architecture, it doesn't also mean that release. Generally true, although we also in case they are some boards blocking release and some don't. The other big hammer we have for support tiers is whether it blocks the general Fedora release or not. That's actually one of the things I would like to soften and I think the rings and lifecycle discussions are kind of about that because I would love it if at the last minute, if there's a bug in XFCE desktop that makes the XFCE desktop unusable, we can ship the rest of the release and then a week later ship XFCE and say, okay, we've got a XFCE release that works or the other way around. Everything's ready to go, but Fedora server horribly broken. Even if it's in addition, it would be nice to be able to say, okay, we've got all this other stuff and we've got a cadence we want to keep to, let's release this and then have a delay for a particular thing. Yeah, that's an easier said than done, but it's a- You would like to do something as key and primary as in addition is severely broken that people would then be- Right, yes. Peter Robinson would like to resort to violence. I would like to put further other record. I'm only going to bring myself up to American expectations. He's slowly becoming American. I heard him say Z instead of Z the other day. So- That was based on- All right, yeah. Yeah, just to say relax, man. All right, any other questions? Are we looking ready for lunch here? If you want to ask Brian any questions, here, I'm giving him the mic. Is any question other than lunch? If you have not already picked up your badge, please do so. They are supposed to be checking those for lunch. If you have not picked up your shirt, please try to do so by the end of lunch. We are going to start trying to figure out how many extras we have for people to potentially swap from chosen size to preferred size on Thursday. That would be tomorrow. There is a question from Brendan for people who are not along the stage now, but go ahead. I'm sorry? The question is, what do the colors on the badge signify? I happen to have a green sticker on my badge. There are three color stickers available for you. Please choose the one that makes you happy. If you have a green sticker, you are indicating that your communication preference is. Anybody can approach you and start talking to you. If you have a yellow sticker, you're saying, please don't approach and talk to me unless I know you. And if you have a red sticker, you're saying I would prefer to initiate conversations rather than have people approach me. So I encourage you to wear a sticker if you like. Yes? The meaning of other possible combinations. You will need to figure out that with the person involved. I would encourage you to consider respecting them in the order of red takes precedence over yellow, yellow takes precedence over green. By the way, these colors were chosen because it's silly easy to buy traffic light colored stickers in a set. They were not chosen to give any judgment about those particular communication preferences. And we've already received some feedback. For those of you who may have issues distinguishing colors, we're gonna look at trying to use shapes next year to help with that. So the only other thing that I have to say is we will resume in this room at 130 with the Amazing Penrose Triangle. So please be here. And then that will be the last keynote for today and we will have tracks in all of the rooms after that. Enjoy lunch. I will see you in this room at 130. Don't forget to pick up your shirt. Thank you.