 So, yeah, we are the Fedora Engineering and Steering Committee. Our primary purpose is to go through the changes for each Fedora release and approve or decline their inclusion in Fedora, and to settle technical disputes when necessary. That has been few and far between for the last couple of years, which is great. People are getting along better. Also maintaining some policies that are not necessarily about packaging. So, there are the packaging guidelines, we don't maintain those. Fedora Packaging Committee does, some of us are in both of them, but there are policies like the non-responsive maintenance policy, or the fails to build from source, fails to install policy, or the Fedora updates policy. This all goes through Fesco and is either written by a Fesco member and then approved, or written by somebody else and then approved. And if there are exceptions to be made from such policies, then Fesco needs to put their rubber stamp on them as well. Speaking of rubber stamps, we have a question in the Q&A. What should the actual rubber stamp dimensions be? Now, I suspect that David was referring to the physical dimensions, but I think it belongs at least the sixth or seventh dimension. We have real questions. So what do Fesco members see as the biggest technical issue to solve or opportunity to take in the coming year? Because he's not going to start us off with any easy ones, like David did. Wow, in the coming year, I'm really worried about the Buxilla thingy, but that's not going to happen in one year, right? Well, I mean, REL 10 is in the next year. Yeah, but as far as I know, REL 9 will keep Buxilla so for the next 10 years, we can keep it as well. No, no, no. I'm not talking about Buxilla. I mean, like from the perspective of what we're going to see in the next year, so 40 branches into REL 10, that means that we're going to see a lot of jockeying in the next year for features that are coming out of the woodworks just to make it in time for the cutoff. So that happened with the REL 9 cycle with 32, 33, and 34 just getting slammed with feature changes. And I expect to see the same thing with 38, 39, and 40. Yeah, it basically happens every time, every cycle. I think one of the better things to come out of the new three-year REL plan, however, is that those are starting to actually spread out a little bit more. And we're getting a few more per release now that people know, oh, shoot, I've only got five Fedora releases before this is out. I got to, people are actually, at least people internal to Red Hat are starting to actually send their change requests earlier in Fedora, which I think is a good thing for both Fedora and REL. If that is true, then it is a good thing. I don't share your optimism, Stephen. That is our dynamic. It is aspirational for sure, as Gwen says. And I think that if that actually does happen, it'd be fantastic. But we'll see if we manage to break any records with Fedora 38 or 39 in terms of number of changes. And if we do, then we're pretty much on track to have the same problem we did last time. Although it's not a bad problem. It's a good problem to have. But it does make for some chaotic development around that time. So kind of to get back to the original question, one of the problems or one of the things here is that Fesco isn't really looking ahead over the next year or two. I mean, we are as individuals and contributors. But Fesco as a body is more reactive than proactive. It's more what are people working on and we're going to approve your change rather than, hey, this thing is cool. We should go do it because we don't actually order people around like that. So yeah, occasional events that that happens. It's because somebody sitting on Fesco happens to be it's think, oh, that's a good idea. I'll go file a change for that and I'll get to work on it. But it's not like we're telling others. We don't dictate to the Fedora project what work to do because that would kind of defeat the entire purpose of Fedora, which is to get ideas from everywhere. Well, I think one way in which we actually do make some proactive decisions or help plan for the future is when we look at some change proposals. We usually take into account is this doable? Is this manageable at the distribution double? What would the fallout be in the next release or two? So we take this the future into account when we make those decisions. But we're not really making proactive decisions out of the blue. So without input from from other people. So basically one to come back to one of the technical decisions that will will be difficult in the next year or so is I'm not really looking forward to the fallout from the removal of JDK packages on 32-bit architectures. And that's not going to be fun, I think. Yeah. That's actually one of the more interesting general questions for Fedora. And I might suggest that if somebody wanted to put this in the Q&A later. Over the last couple of years, we've definitely as Fedora changed the way that we've dealt with language stacks as a whole in Fedora. And I'd actually be a little curious to see people's feedback on whether or not that seems to be going in the right or wrong directions. So anyway, have we avoided the Ben's question sufficiently at this point? Do you think? I just wanted to say that one of the technical issues that will probably hit us very soon and might be in the coming year is to pack your stuff and get lab stuff and the general get forge idea. It's like hanging in the air somewhere where it was the decision has been made and nothing is happening. So we'll see what Fesco will have to do with that. I will say that it's not that nothing is happening. It's that nothing has been particularly visible. And that's probably what I mean, nothing is happening because when something invisible happens in Fedora, for me, at least, it's like nothing is happening. I mean, it is nothing is happening. If it's invisible, nothing is happening. Yeah, like there is a lot of invisible things. But, you know, from people's perspective, because they're invisible, they're not happening. And then people ask about it and it's still not happening because it's invisible. So like it's not happening. Yeah, and then things just kind of land Feta company. But we'll I'm sure we'll try to be more open about the get like get lab stuff once it gets to a it gets to a point where we actually know if it's even feasible. Uh, so if anybody else has anything for this topic, otherwise, we've got another one. Why do packages, some packages not get pushed to updates? For example, LibreOffice 735 is not available for Fedora 36 on Boat even though there's a Koji build. The meeting hasn't been edited yet. Like some nobody did it. Somebody needs to do it. And if nobody does it, then it's not done. It's that simple. One thing that's a little different from Fedora versus other distributions is that when a build actually hits the build system, it is not auto submitted to to be considered to release for updates. Someone has to manually do it. That may be something that will change in the longer term future. But we'll but for now it's not. It's sort of you can kind of see what that workflow would look like with raw height as it does that right now. But for stable updates so far, that isn't a thing. So that's the more general answer as to why you'll sometimes see builds in Koji that never make it to people because that happens or doesn't happen for really. And to be fair, it might be that the maintainer pulled that down and tested it and found some problem and they're working on it or there's a lot of other build or there's a lot of reasons that could be going on there. Really, you'd have to talk to the maintainer. Well, it would be really great to extend the automatic raw height workflow to stable releases so that you could somehow when submitting the Koji build, mark the build as just proceed with the update for this. I don't want to look at it again. There's a lot of things I would like about automation to go forward in Fedora stuff. I realistically don't think it will ever happen because there's too much resistance to that kind of making people's lives easier. Well, I see this as well, maybe not resistance, but lack of plans for this to happen. I mean, like people don't seem eager to implement this and I don't really understand this because I think it could help us a lot. I mean, we have like RPM Autospec done halfway and not moving forward for the last year. We have some Q&A Automatism in place, but it's moving very, very slowly and it should really move faster. Well, so there are two big problems with the way everyone approaches automation in Fedora. One, people have to do stuff and two, it has to be we can't do basically life changing, a flag day life changing events for things. Those two things make it extremely difficult for Fedora workflows to change, whether that's for something positive or something negative. Like for RPM Autospec, for example, to, if we wanted to actually make, no, RPM Autospec is developed in so far as all the pieces are made and whatever. But like if we wanted to make RPM Autospec like 100% part of the thing, we should have just adjusted the build system to make it so it always ran and got used. But we don't want to do that. We want to make it so it's opted and slower. There are good reasons for doing that because it is a workflow change. There are aspects of it that need to change. There are different considerations, but it is still fundamentally the approach that we have for every modernization so far has been that it has to be done piece by piece. So take, for example, the EVRB proposal that Alexandra Fedorova has up on the mailing list and on discourse. So far, the whole mindset has been around, let's make it so people have to change their spec files to make it work. That's going to make it fail. Like to put it bluntly, any kind of modernization proposal that requires people to do work to take advantage of it is going to make it fail longer term. It may have some adoption by enthusiasts, but longer term across the long tail, you're just not going to get the adoption and we'll always be stuck. So there's a mindset shift that has to be made in order to think about automation if we want to have a broad base adoption and truly make things easier for people, but to each his own. Well, I think that you make it sound as if we actually wanted to have flag days. That's the whole point of Fedorova stuff. Well, experience says that, it's my experience, my understanding of things is that you need to find a way to introduce new features in a way that does not require flag day and it allows a slow, incremental switch where the old stuff still works as long as possible, as long as there are users. I think that RPM Autospec is a good example. So right now it works and you can opt in. You can, we can, for example, make an automatic switch of, I don't know, last crates one day and maybe Python packages the other day, but the old stuff continues to work and this is good and it should continue to work. The problem I see is that there's not enough integration in other places, but the fact that the old stuff continues to work is actually a plus in my view. The old stuff working is not mutually exclusive to we actually like actively change things to use new stuff if that's the direction we actually want to go. The problem is that there is essentially, there's essentially no path that people are thinking for these kinds of things to make it so that new things are working. For a simple example, we've had Koshay for six years and we've been talking about turning it on automatically by default for all packages for four years and it hasn't happened. That is a very easy flip to make and we should have been doing it and we're not. And that's the kind of stuff where I'm like, it's very clear that on a community basis, we don't have an agreement on whether we want to improve the scope of automation and how a package or workflows work. Neil, for the benefit of those who may not be maybe less familiar with some of our, obviously, not primary tools, could you explain what Koshay is? Koshay is a dependency tracking auto rebuilding tool that walks the tree of things that are in the build system, Fedora Koji, and as things churn and change, it tracks them and triggers rebuilds of reverse dependencies and gives you reports based on whether they're successful or failed or whatever and gives you an idea of mostly real time, the repo closure state of a given distribution release. So it could be 35, 36, Apple seven, eight, nine, Rawhide, whatever. It's by far not perfect, but the fact that it's not on universally makes it very difficult for people to figure out whether a change, what kind of scope a change particularly has. Ahead, that's one problem with Koshay is we are testing these things once we ship them, not before. I mean, I have a whole lot of things I could say about about how our build and release pipeline works, but that would probably turn this into a giant rant, and that's probably not a good idea. We are slowly getting there anyway, because when we meet in one room, it's always the natural outcome. Let's figure out the next question. I can't mark stuff answered because I guess I am locked with a different account. So the next question is, are there some examples of proactive guidance that the council has provided to working groups? Not in recent memory. Not that I assume. I assume David, when you said council, you meant Fesco Committee, because we're not a council. I mean, we are, but we're not. We don't call ourselves that. Perhaps. Let's talk about the name. Proactively, I think, well, it's not entirely proactively, but we did, and this is dabbling a little bit in another question we got for later in the list. When we were approached about the FlatHub question, I think that we, I think our response was reasonably proactive in that we identified and told them what changes we would need to need them to make in order for us to come to an agreement about including it. Does that, I don't know if anybody else can think of a better example, but. I think the last time we were quote, unquote, proactive about something in any serious capacity was when Fedora Corrios tried to become an addition the first time and the second time. I think the third time's the charm this time and they might actually do it. But that one was yet you're not in good shape here and here are the things that we need you to think about before you try this again. But that's I think the only example I can think of where we're like we proactively said here's what you need to actually become a reality here because other than that, I think we're almost entirely reactive and that may not necessarily be a bad thing either because in many respects, Fesco is mostly hurting cats than it is setting the road map. The roadmap is post facto, not so it happens after people have started figuring out what they want to do. So it's the nature of the beast here. It's sometimes happens that individual Fesco members or even a small subset of Fesco is proactive about something but it's just because they would be proactive about the same thing even if they were not on Fesco. So like as a committee, we are not proactive, we are reactive, but as an elected body, it's the proactive people that tend to get elected in Fesco. So individually, I think a lot of Fesco members are very proactive as a as a committee, not so much, which I think is it's alright. That's how it works. I think there has been a little bit of proactive stuff around some of the policies like where we're going Oh, this policy is not great. Let's redo that. I don't know if that's more reactive. I think it could be considered a bit of a blend in that respect. Yeah. Yeah. But like speaking of members being proactive versus the committee being reactive, I know, like personally speaking, I have like somewhere between a three to five year roadmap of things I want to see that I want to get done within within Fedora releases. But you know, that's that's basically like part of the reason I'm on here is to kind of be able to say like bring my view of like how Fedora should evolve and show it to other people and and make sure that we can put our input into guiding the future of the distribution as a whole. But again, it's all post facto, right? Like these these changes have already been proposed. People have already probably started doing the work for it, even even if they're not approved yet. And then it kind of just rolls on its own sort of kind of maybe. So should we try to take more proactive role? Like, for example, in the question about Koshay, because I think that the issue is that there is just no single owner of who feels like they can say the whole distro should use Koshay, because it's not up to the Koshay developers. It's not up to individual developers and there's just no owner. Let's do it. Sure. Why not open a ticket that we want to turn on Koshay automatically for everything? We'll rubber stamp it with our giant rubber stamps. Yeah. Okay, so of course, the ultimate question is now, who does the work? It's not just a configuration change or is it? I mean, does it work? Will it scale to that number of packages? Oh, that's a configuration change. It's database change. It's changed the new package flow because it needs to enable it automatically. It's, I don't know, probably there's probably half a dozen things that need to happen. So, technically, we can just say that we want it and then we figure out the details later. Well, at minimum, we did minimum someone needs to step up, file the change and be willing to shepherd it through. If you want this to be a change proposal and definitely do that, let me put it to my never ending video list. Oh, you've got one of those too, Miro? Yeah, it's basically like, like a buffer when I have new lines on the beginning and the rest just like goes somewhere. Yeah, I'm pretty sure mine wrap would wrap around the earth at least once. Yes. Yeah, I think I'm at that point about halfway wrapping around the earth now. I want to stop here about when we discuss coaching and packaging automation and stuff like that, but I see one one challenge and I wouldn't say a problem more like a challenge that is even if we enable coaching for all the packages. There will be a large group of packages who wouldn't look at it or who wouldn't concern their package not building interesting for them. And it's the same with pull requests and CI and stuff like we got a lot of very cool stuff. And it feels to me that some of our packages are just either not interested or not aware or just like prefer direct push to this kit, even if it doesn't even produce the source RPM, because that's how they've done it 10 years ago, or that's how they've been taught to do it by somebody who's doing it for 10 years. So even if we enable coaching for all the packages, packages, then I'm afraid that for most of the people until somebody files their bugzilla or even until I tell them after three releases of their their package not building that they really need to fix it, they won't. And no amount of automation can can change people's minds about this. I think this is particularly challenging because if we want to make something cool, you know, we need things to change and people don't like changes, right? If you change something, they are not happy about it. So some of it is that. OK, go ahead. Some of it, I think, is that a lot of these quote, unquote cool things that we have are kind of out of the way rather than in your face. So, for example, most people probably don't even know that when you submit an update to Bodhi, it runs a battery of tests on them because it's out of the way and you don't notice. And I could also make the argument that that's actually the wrong place to run the test because it should actually fail to build in Koji, market has failed and all that fun stuff. But point is a lot of the things that people say that we're doing are all background things that everybody can happily ignore. And and my experience over almost 10 years of doing this in a professional environment is that if you make it easy for people to ignore it, they're going to. So you have to kind of smack them in the face a bunch of times about the about the changes and the new workflows and things like that before it will actually take effect. Like I already hear from lots of rel developers who are kind of mad that they have to use merge requests for every bloody change to send us stream because they can't actually directly commit to the repos anymore for send us stream. And so they get a little twitchy about the whole workflow and all the C.I. things and all that other fun stuff at the BZ approvals. But because it's smacking them in the face, they can't ignore it and they have to deal with it. Like we can easily make that the same kind of smacking people in the face with with our disk get set up for some of this stuff. I don't know if we want to take every single step all at once. I'm pretty sure that if rel developers weren't paid to do it, they would all left. So we should do it a little bit more incrementally, but like, for example, making it so a commit landing could be held in a staging index until a C.I. test passes and if it fails, the commit is rejected or something like that. Like there's a there's a lot of different things that you could do to make those kinds of workflows more in your face and make people care about them. Just as a side note, I would answer. Sorry, go ahead. What I just wanted to mention that I actually have some amount of data to back up that what we started doing to poke poke people to fix their packages. For example, the enforcement of the failed to build and failed to install policies is actually having a measurable impact on the quality of packages in the repositories. I have some historical data. Because I'm running the the service that provides the broken dependencies reports for the package dashboard. And the number of packages with broken dependencies or rather the number of broken dependencies across all packages has gone down from over four thousand for dollar thirty one to just eight hundred in four dollars thirty six. So that's 80 percent fewer broken dependencies in the repositories. And I'd say that's a good start. Yeah, I think it's excellent. Sorry, Spichek wanted to say something for like five times already. Yes, so I'll be quick. So I mean, I kind of agree with Neil that that it should be harder to ignore stuff. But also I think that there's another aspect to this. It's hard to consume this stuff, like the connection between Pazure, this gate and Koshay and release monitoring and the Q&A checks. It's just so hard to follow, even if you know what you are doing. So we need more visible connections, easier ways to to to to look at things and so on. Packager dashboard is excellent. It doesn't integrate everything, but it integrates a lot. But I think we should we just need to move in the direction of having this just easier to click. And if we probably sorry, sorry, I did want to just interject one quick thing about the package dashboard. I completely forgot it existed because it is not prominent in any in any meaningful way. And I think we probably ought to be at least linking to it from like Bodie and from any of the tools that we interact with regularly, you know, have a banner. Hey, have you considered looking here for the for all your packaging needs? It's not even linked from the Fedora docs. Like I don't even know where you would discover it if you didn't already know it existed. Yeah, so I think we probably I think that's one of those places where we can probably be proactive in this committee and go ahead and do something about that. Sorry, I I interrupted you, Fabio, and before that, you were colliding with the venue. So I think we should let you speak for a change. Just wanted to mention that since we're talking about test results in Bodie, every time I get getting test failures or something for one of my packages, I have no idea what the test failure is because I have to dig through Jenkins console locks or something. And I for the life of me, I can't figure out why is some why a test failed or something. And I just waived the test result because I don't even know why it failed. And I can't see the failure. And there's no obvious way where to to to see that. And there's no big red banner. Your test failed because of X, Y and C. It's all buried in some kind of log somewhere. And that's not really helpful. Yeah, for what it's worth, it's not better on the incentive stream either. It's arguably worse because there's no there's no anything that points out failures. It's just, hey, your things not your things failed. Good luck. Does it all can include a link to the failed tests? Yeah, but you can't get to the artifacts. You can't see what the what what actually were the failed things that build because it's all on the red ad firewall side. That is something we can probably work on. Could you file an issue for it? I'll look into that. Yep, sure. I was I did not realize that was for lack of a better term pay walled. Yeah. Hey, I'll be happy to be paid to see the wall. So I think we we should wrap up because we are we are scheduled until six minutes ago. So no, I think we are scheduled for the entire hour actually. Yeah, I'm pretty sure we are scheduled for the whole hour. Oh, yeah. OK, that's good because we are so popular. That's why, yes. Hey, there are 70 people on this call. So. Hello, everybody. OK. There is more question and answers. Thank you. Let's go through them. I can't this is a good market that was answered. So here's a good question that I don't think we've answered from Marie. Do you think it'd be useful to have more connection and collaboration with the mind share side of Fedora, for example, marketing design ambassadors? If so, how would you like to see this happen? So my answer is unequivocally, yes. There needs to be much more bringing those two groups together for for general advocacy in Fedora. My in my particular line of advocacy that I do, it is almost always connecting these two pieces together and presenting them in a way that other people find it very appealing. So I think that's something we should strive for as a general practice. I don't have specific ideas of how to see that happen. But any of the others, what do you think of this? I have an opinion as well. I agree. Definitely, we should do this. But I see that it isn't really working. It's not only mind share. It's all the council business as well. For the past few years, I think that Fesco and the devil mailing list for Fedora and all the package maintainers and the people who do Fedora changes is moving one direction and the rest of the project, the council, the mind share, the discuss thingy, the non not using mailing list stuff is going through the other direction. And there is this huge gap in between those two words. And then some of our people are actually able to navigate like both of the words. But I think we need to start interconnecting those two words more. There have been decisions made that haven't been discussed on the devil list because the people from the other group don't even subscribe to it because they don't like it there. On the other hand, then we discussed something on the devil list and Fesco and then the ambassadors have no idea or I don't know if we even still have ambassadors. I think we are getting a part and we should definitely do something about it. But I have no idea what. So the lack of physical flock has been an issue, I think. Hopefully next year we can meet and actually talk in one room. I also think that more interconnections would be good, but I don't know how precisely that should work. Yeah, I agree with Zivik new. I think this is actually because we don't have any synchronization points anymore. Like the flock events who historically have been the place where we've gotten the Fedora advocates, ambassadors, whatever we're calling them now, along with the developers and other contributors. And we get to refine and pull together our strategies like the nests aren't working for that particular for that particular goal because you can ignore them. But like it's it's much harder to ignore when people are coming by and saying hi to you and want to hear about what you're doing and talking to you directly. Whereas with these. On much more structured things. It's much, much easier to like just put aside a whole portion of the project and like operating 100% virtually for a few years, I think is what's led to the splintering as Miro that and creating that gap. There's something to be said too for perhaps we can work a little bit in the with the change process here and perhaps we make it more we should push for it to be more proactive that people submitting changes also communicate with the mindshare team as far as sort of treat the treat mindshare sort of a little bit like a product management team where they get involved with all with all the they get involved with at least figuring out how to how to market and how to sell the the new features. Maybe I guess I guess that's not really product management that's more. So one thing we had that was aimed to make the council and Fesco kind of more coordinated was we have a Fesco representative who's on the council David to like go to those meetings and share anything back. Maybe there should be a mindshare person also that goes to Fesco and shares things back or maybe we should have a Fesco person go to the mindshare side and share things back. But yes, it's a difficult problem I agree. And I'd love to see more coordination somehow. Yeah, I think it would I think it'd be a good idea to have interconnected representatives. I think the theory has been that mindshare that mindshare and and Fesco exist as members on council is the synchronization point, but I think in practice that's not working. So I think we need more cross connections, especially if we're in this more heavily virtual thing. But I don't know if council is actually functioning properly for this purpose, which I think is like kind of the whole point of council right now is to be that top level synchronization point between the different wings of the Dora. So I don't know. What about the quarterly council Fesco mindshare meeting? It might be. Sure. Yeah, we could we could do something along those. If I remember correctly, council does either an annual or semi-annual face to face to figure stuff out. It might actually make sense to do something similar for like all the wings of of Fedora in some way, Fesco, mindshare and council. But. Yeah, that'll be interesting to organize somehow. I think David does make a valid point for most purposes. That's what we had been using flock for. So maybe but maybe flock needs to be slightly more frequent or maybe we need to have an in-person event and a virtual event back and forth half the year. Yeah, maybe we have maybe flock is in the summer and nest is in the winter from once we get back to in-person events. Yeah, yeah, no, that may actually that that would work out quite well because I definitely hate traveling in the winter. So the virtual events they have been great for outreach to community. I think it's it's just easier for people to participate this way and we certainly should keep them. But the alternating sounds good. So there was another question. How do we measure our success as a as a body? And I think that like one way to look at this is just to see that if you are responsive to tickets and I think that we mostly are. Sometimes things get stuck, but I mean, it's not so bad. But I another way would be to to to to look at this as our ability to to to look into the future and do proactive steps and on this we are well, not so good. I would like to say that as an elected body we can determine our success that people keep voting for the same people over and over again, mostly. But on the other hand, to be fair, the list of candidates isn't really exhaustive, like so the vote is not like you could actually vote out everybody and vote in the new Fesco, right? You can actually do that. We do let people put zero and if they're zero, the seat does not get filled. Yeah, but everybody everybody would need to vote zero. So when you run and you vote for yourself, you can't get zero. Well, I think there's a I think we can probably figure out a reasonable lower cutoff that just says that just says if you're under this average score you know, you are not a viable candidate. Yeah, so I would like to encourage people who are here who are interested about Fesco. Do you actually like subscribe to the Fesco tracker see what's going on and if you're interested in this kind of stuff and if you have ideas don't be afraid to run. The worst that can happen to you is that you actually get elected and then you need to do stuff. Don't say it like that! Well, yeah. You can always resign when you don't have time. So it would be really, really cool if we could have multiple candidates for the next election. It's kind of boring when you have four seats and five candidates or something like that. And then resign, right? It's time sensitive. Yes, if you want to be proactive in Fesco it eats a lot of your time. But we also it's perfectly all right to just join the meetings give your pluses ones and minus ones and then go about your business. Right? And also like most of the time we don't actually have to do a lot even with trying to be proactive in Fesco. Like the last couple of cycles we've had two or three issues which have forced us to have meetings but like the cycle before that I think we only had one and that was the I'm not sure pipe wire is going to make it are you going to make sure you pull it out earlier before the deadline even though that's a change says do it on the deadlines like yeah yeah yeah whatever. But like most of the time most issues go through without real issue. Most changes roll out fine and actually we've gone months without having a meeting because we're just rubber stamping all the things that don't that aren't really controversial. It was much more when modularity was the topic. Well there were meetings all the time during that one. I think another thing that takes a lot of people's time is if you want to stay up on the develop list discussion on everything because sometimes there's very long threads of esoteric things and people are generally in favor of something and then nitpicking further. But yeah. Okay can somebody who has the right mark the questions we answered that's answered and let's pick another one. I don't think we can extend on the internal forging because we don't know anything about the answer flood have I think I can answer on behalf of the committee that we didn't approve that you can read it the logs it was one of the this was interesting I think we will see a modified version of the proposal hopefully that might be better. To be clear we didn't approve it as proposed we provided feedback to tell them what they would need to change in order to get it approved which they couldn't commit to for Fedor 37 so they're going to retry for Fedor 38. Yeah. I believe the most important concern from Fesco was that we provide content to the distribution and suddenly that content would be like replaced with third party so we would like Fedora content to remain the primary stuff people install when they run Fedora. Yep. It's simplification but it's more or less a known software specific bug because if you turn on third party in Fedora KDE it already does this so it works correctly in that respect. There are vendor preferences, source preferences that whole bunch. Genome software has never implemented this and now they kind of have to go back and do it. Once they do we'd be happy to take it. So is there a dedicated place for technical change or announce? There is develop announce list. The problem with that list is that it also targets people who are developers about important stuff that's going to happen to them. I don't think there is like one place where non-developers could see what's going on in some announcement like fashion. Honestly enough we do actually have Veronica for that purpose because every time we approve something Veronica yes so that is actually a valid place to look although his editorializing is usually pretty fair but there is some editorializing in all cases. But that is actually a pretty decent place to get a good list of... And don't read the comments. That's a good rule for any site anywhere. Except for ours. Yes because we are all friendly and we never shouted at each other and stuff like that. Yeah never at all. I wanted to say that I think if... But again it requires somebody to do it. And with all the interesting ideas this is probably the most important blocker because nobody has time for that. If we advertise our changes on Fedora magazine or something like that so you propose a change it gets approved then somebody from mindshare takes the time and writes an awesome article for Fedora magazine that summarizes terms that don't require knowledge about packaging or whatever and we can share it on social networks amongst the users or potentially users. But I believe that's really hard. We have the release notes tracker and for every change we want the release notes and even that doesn't always happen. Yeah No it doesn't. I know that developers usually are pictured as people who don't like to write documentation I don't know if that's correct or not but I really enjoy explaining what I am going to do because I like feedback but I write long change proposals for simple stuff. Usually the code is like two lines and the change proposal is three pages. I'm pretty sure that this change beat you on the length for a simple change. Yeah But I mean I wouldn't have the energy to then go and rewrite that change proposal to a magazine article because that's like too far fetched for me but if we have people who would do that I think that would be awesome. For what it's worth devil announce is you know I'm looking at what actually ever goes into devil announce and it is mostly change announcements I don't really see that and milestone announcements that all of them are Ben Cotton things more or less. And me sending all front packages that's absolutely not related to people who are not packages. Yeah but it's low traffic enough that you can filter between them. Yeah then you have the we are going to rebuild stuff everybody stop doing anything and that's also not interesting to me. I just wanted to say that if I were not a package I would not be interesting in devil announce that much it just has too many packaging stuff on it. But it's low traffic It's low traffic and like in the span of a quarter you get like maybe 20 emails and the thing is I'm looking at it and yeah so even in the last month more than just announcements of change proposals and then the rest of them are milestones but it's still I think of interest to pretty much everyone. Well there's a difference for packages it's of interest before it happens and for users it will be actually of interest when it's implemented So I kind of like the idea of magazine articles that you could read about features when you can test them. For the stuff that's not going into release notes or not going through the change process we've set up a new feature spotlight project where we're collecting ideas for magazine articles we've got a few suggestions for topics but nobody actually showed up to write the texts for those so it's the same problem if it were about topics where I actually know what I'm talking about I'd write them myself but the suggestions we got were about things that I'm not really an expert in so we need somebody to actually write those articles and that's not happened yet but I'm hopeful that we'll get the first feature spotlight article out this year It will also be a nice way to contribute for people I'm sure that many developers will be happy to have somebody work with them on preparing an article if they don't have to write most of the texts themselves Yeah, sure that would be a good way to contribute if a user knows about the project and knows how to how to describe how to describe how it works and what it does then sure that would be nice to have them contribute a few paragraphs of text for an article I think we're almost out of time anyway if I'm reading the clock correctly So I think we have time for maybe one more quick question I guess the last serious question here is will there be some kind of open firmware thing part of the door someday maybe as a more hardware specific endeavor, maybe not so appropriate I think this is actually probably accidentally kind of happening a little bit sort of the ARM situation is horrible and so because of that we have all these things like UBOO to do fake UEFI on a whole bunch of things doing the mobility stuff where we got to pretend to be more things and I know somebody is going to say that UBOOT is not fake UEFI but if I have to control it then it is fake but whatever that's just... anyway point is I think we're accidentally moving in a direction where we are going to have to care more about hardware services part because the new hardware platforms that are going out there do not take responsibility for their hardware and so the software and the operating system has to do more of it so I think on the longer term time scale we're going to wind up doing that even if we don't really want to and most people aren't interested in it it's just going to be the nature of the beast especially as we move into ARM and RISC-5 and these other platforms that just aren't mature in terms of this separation between hardware management and initialization and software control okay I think we answered all the questions we already have some arguing going on in the chat that's a good time to end this also I just wanted to take a moment to say thank you to everyone who voted that I should keep the beard and mustache appreciate that yeah you look good with it, seeing you in person is way better I appreciate it if this was the least favorable option you would put it down or you just like that the people agree with your own opinion honestly it's much this happened much the same way that yours did I got lazy while working from home so okay folks thank you very much folks thank you