 Okay, let's start. We're a small committee, that's good. Yeah, the problem is that my laptop crashed. I got a spare laptop that I haven't had the time to set it up. It has password but I don't get it at all. So I don't really need slides, I have units, so just to keep track of my talk, but it was supposed to kickstart a discussion about our packaging tooling to include page management, because it's a recurring issue and well, we'll see. Well, so my name is Iqo. So I'm part of the Fesco and also Cloud Working Group. In my day job, I tried that on OpenStack. So I'm the audio guy basically. Yeah, it's just new too. I can't share it later because it's kind of my laptop broke on Sunday and couldn't finish. It's just that I don't get lost. So I've been a packageer for 10 years. So I've seen all the different practices and also the bad practices. And we are currently in a short state for page management in packages. So first, federal policy is about upstream first. So we're not supposed to ship patches in our packaging. At least that's the default, no patches. But some patches are not upstreamable, like some specific federal integration, or there are also patches that are refused upstream that otherwise the package couldn't work on federal. So we have to bring these patches in our packaging. We can't avoid patches in some package because there are security issues or backports that are missing required because we can't wait upstream to release a new table to do a new package. So we have to back for the patch and keep it in the package until we update to the latest to the latest release. But so we don't have a choice. We have to deal with patches. And that includes many critical patches like JLPC, kernel, Firefox, many critical path packages in federal have patches. And we have to manage them sanely. And mostly it's interesting to see that these are the packages who started experimenting things, but in how we manage patch. If you see how the kernel manage their patches, that's quite interesting because they finally have a working workflow. But the problem is that the workflow, which is pretty much the same, is not adapted, is not implemented in our tooling, and is not also documented by so other packages could reuse it. So I think that as part of the packaging, as part of the technical community, we should fix that and and say to the package, okay, you have to manage patch. Here are the tools here are the good practices. Well, we're not going to tell you how to do it. But if you do it that way, that's the best way and the most same way. And that encourage contribution. So I will come to that. So currently, the patches are version in this get. So they are version as sources. So you can track the changes in your the other patches. In the spec, you declare them with a patch, followed by number line. So you have to insert the line each time you had a patch. And you apply them with a special macro, which person patch number page and then apply it. It's kind of very rough, because you have to do it manually. Every time if you are managing packages with a lot of patch, it could be very cumbersome. Currently, I'm maintaining I'm commenting in most of the open stack packaging. And we have a lot of patches in some cases. And every time we have to roll out a new release, we have to rebate the patches. Sometimes we have to have new patches, remove patches. And we have to do it. And we had to do it manually. It is really annoying. So we decided a open stack patches are managed by get. And that's how I do the transition. Oh, sorry. I'm going to mess up. Sorry. Yeah, but the protector is not used. So yeah. So there is also a problem how we generate patches. The very old way was to use diff. So we even had a few option where that where recommends and a you are for generating patches. But most people ignore that. So you get you get to apply patches on top most directly or inside a directory that was the total mess. The newer practice is to leverage it. Okay, if your project is not managed by get, just unpack the table, create a temporary repository, change things and generate the patch. And next time you have to do it, you just import the patch and fix it. So that's the way how we are that is recommended now to do patches. Some projects like Docker maintain their own gate repository and manage their patches on their repository. So that's available, available publicly. But the problem is that we can that they're managing that in their own repository. And nobody may not everyone knows where it is. And it could change from a package to another. So so we need we need to find the consistent guidelines to say, okay, you want to manage your sources at side, we'll have the infrastructure we are currently building a tool called Pager, which is kind of GitHub like clone for both for Fedora, but which would be reusable by anyone. Pager. Yeah, exactly. VAG URE.io, I think. Yeah, where our canonical. Exactly. Oh, that's fine. We're a small community. We're here to speak together. That's not me speaking to you and you listening. If you want to interrupt me. Yeah. No, we're here to discuss an example. So we have the tool we have. We are having the basic infrastructure to host gate repository. So we just need to tell people that they should move to this pace. That should be a guideline saying you want to manage so so people could say that we have even a pull request mechanism. So that would be awesome because we'd be able to encourage people managing their patches to collaborate together in same repository and maybe one day on the spec file. You have the whole thing. Yeah, exactly. That would be the awesome ending of all this. Yes, all of this. But so we have the tooling. The only part that is missing is the packaging tooling, like Fed package, but doesn't allow you to manage properly the patches. And that's here. I that's here. I will be saying that the problem with all that the current approaches is that it's far dry because you have to think speak manually. The collaboration is not smooth because you have to search where patches or if there is actually a repository to manage patches, there is no way to track patches because, for instance, you cherry pick a patch from upstream, but you don't know if when you release a new new package, you don't know if the patches you're using have been taken because maybe you had to change things. And so the checks and change and you have no way to check that you are already shipping that patch. So which is stupid because Git has a way to tell to track patches. If you do cherry pick dash x, it will include the original checksum. So you the tooling would be able. Okay, the original section is it? Oh, this is already in here. So I will drop this patch automatically. And you don't have to care. Yeah, exactly. But it's still helpful. So now, to make things more smoother, we can already drop the clutter in the space because we have this cool macro called person auto setup, which will be applying patches automatically for you. So you don't have to worry in adding and removing the person page lines. That's not used anymore. By default, it uses the patch utility to apply patches, but there is a switch, which is dash the uppercase ace, Git, which will allow to use Git directly to apply patches. So if or we had some kind of tooling in that package that allow you to insert patch lines for you, you just if you're using auto setup, you don't you don't have to care and you don't have to do a lot of parsing to have this because patches are and source lines are pretty much commonly in the beginning of the spec and don't move much. So what would be right? Yeah, yeah. And the most awesome is that it's supported in RPM 4.11. So all supported federal already have it. Seven. Yeah, exactly. People said it wasn't working, but I tried personally and it works pretty much fine. Yeah, the only thing is that you'd still have to have build request get because it's not in the build route for ER7. But it works pretty much fine. And it's and I think that if the only blocker for people is that all I must have the boot request get, well, we can manage to have it in the default build route because Git is pretty much profitable nowadays. So by leveraging already RPM filter, we reduce the clutter. Now we have to use Git as we already suggested, because a lot of upstream projects already use Git. So why using something else? And this is also the default SCM of Fedora, actually. So if it doesn't, you can, if it uses another SCM, you can sync it. You can sync SVN and Mercurial repository to Git very easily. It works fine. So we could have some kind of syncing repo between Tagool and the upstream repo to keep that in sync. If you don't, well, we could, I know that Debian has a way to version sources. It takes trouble and it will add them to Git repository and you can manage your page on top of that. So we could reuse that as the same approach. So nothing is actually preventing us to do it. We can already implement it in local way, but if we want to implement it at federal level, we already have the base tool doing it. So you just have to do the glue and make it happen. So life would be much easier if we do that because we automatically rebase patches. If we do cherry pick dash x, it will be, we will drop patches automatically as soon as they are included upstream. So why we're not doing it already? The good thing is that I've been experimenting that workflow for one year. Erdio already does that. We have some specific tooling that is called Erdio packaging, which could be used for federal package actually because it's a tool built up on Fed package and Erdio package. So we are already experimenting on other projects that people are already using it to manage their packaging. So this approach works. We have tried it and it's pretty much reliable. The problem is that Erdio is very specific tool and I prefer that we include the patch management part in Fed package because it would be much more useful to more people. So the idea is that we need to agree that this is how we want to encourage people how to manage patch. That's why I'm here speaking because I could just send patch to Fed package and do it. But the problem is that, well, but you're forcing something on us and Yeah, there's a cultural problem. There's a cultural problem. So you have to convince people that do we agree that's the preferred way to manage patches? Okay. So if we agree, let's implement it in our tooling in either our reference structure and then advertise it. Yes, don't make it mandatory. Exactly. I don't want to force because if people have working way, Okay, I'm fine. But yeah, but for instance, I'm proven package. I don't want to spend a lot of time checking how people manage a package in very standard way that would make my work much more useful to fix packaging and help people because that's why we're here problem package. We're here to help people fixing the package. Okay, you don't have time to fix that or you can't fix it. I will fix it for you. But I'm not doing the maintenance. I'm just here to help. So if you want people to help make it easy. Don't don't have them reading a lot of documentation or spending time searching things make it. So oh, you're managing patch the standard way. Okay, I know how to do it. I know when I will find things. Oh, maybe Fed package will help me to grow your patch repository and we'll be able to update it myself without breaking anything because the process is already documented and straight forward. So that's the goal. So okay, the minots are handling here. So at this point, now I would be I would have wanted to have some of the air package people here, but apparently nobody from the tooling group is here, but that's not a problem. I will do the interface. So I think we shouldn't doubt we should see if we have to change anything in that policy that I'm suggesting because I plan to suggest it to say to propose it to the Fesco at some point and have it implemented. So I wanted to have feedback. What do you think need to be changed or added? So I have a general question because you say that we should have keep the system or we have the turbo and build the patches on top. And why not simply get rid of the turbo? What could be where? With the gift of the source project. It is 9% of packages are packaged in the same way as the package in the other regions. Just for the moment, since we are recording, are we just at long the discussion? A lot of ups and project are using it. So why not directly using it and just sort the checksum to generate the package from that instead of using the turbos. Now, can I save you a little bit of time because this is a discussion. This is the third or fourth time I've been part of the discussion and in case you haven't, I'm on FBC. We've been through this, but we've not been through this in the new get dominated world that we seem to be in. The main issue that we have always had is reproducible builds that are managed from that can be completely done without external access to anybody else's repository. Now with it, we can obviously now clone a repository from whatever upstream has and use that and have the checksums so that we can ensure that we've got it right. So now may be the time to consider that again, but if you're talking about a big cultural issue and you're talking about a pretty big overhaul in the way our infrastructure works. Yeah, because actually the packaging are extracting turbos from the Lucas doesn't manage it at all. Yes, the tar balls just come from a separate easy to storage repository within Fedora. There's nothing technically preventing us from doing the source some other way besides somebody has to write the tooling and you're right. Now in this universe right now, it's a good idea. But the last few times it's been brought up. It was not necessarily a good idea because we just don't see the answer. I think I agree that's a great idea, but I think if you want to maximize your success, it should be separate proposal because it doesn't because if something in the if you bundle a lot of proposal, it's only a very small thing that is preventing the whole proposal to move forward. Yours will be stuck. So propose it separately and I owe and if it happens in fiscal hand, believe me, I would be I'll prove it because this is the right time to consider this. We have the tooling to clone repository and saw them. Because the problem is that what people were using source forage and now source forage is closing a lot of repository. And this is horrible because now we lost a lot of history and by using the look inside catch with turbos, we are preventing some such issues to come. But now we can clone get repository and sorry son, that's a good time. And if you want to push that, you I'm pretty sure that now people will consider it and there are people including me which will be pushing this forward really great thing. And that's also nice to see too. Yeah, I just want to something loosely related to that that's been project atomic and always true. Yeah, right. So they basically for a subset of the packages, they do what you're talking about. They don't build them into packages at all. They build directly from source but anything that doesn't you're advocating, it makes it easier to constantly keep up with what's going in source also makes testing in QA that much better. It removes a huge roadblock which is another thing to add, you know, if you are looking for ammunition to advocate for that, that's a big one. And Debbie essentially already does this. It went through an evolution. This is my understanding of the way the packages have always been the spec files, just a main file. There have been a variety of competing mechanisms for optimizing that main file. And the one that is currently most popular now for something like 50% of packages the spec file, the main file is just a few macros and that's it. Because it just knows it's a few heuristics are pulling stuff down from source and it just built. And that's what we want for the majority of packaging because the problem is that it's a lot of error prone and we want to minimize errors because a lot of contributors don't have many times and as a package or packageer sponsor, I spend a lot of time explaining things and it's always the same thing. So I want really to make it straightforward. I want 80% of the things we do should be straightforward and people don't need even to ask because, oh, I need to use this macro. And we spend the time on where is the heart of the packaging, the solving each integration, issues or very tricky ones because we are very small core of contributors. If you see Fedora as a lot, as thousands of people registered on Fears, but in terms of packaging, we should have 1000 something like that. And if you downsize to the people who are doing that regularly, it's less than one or 200. And one or 200 is quite optimistic. So we want that the one, the occasional packageer spend the less time doing his package right the right way. So I think that at this point, also, we have to see what are the tasks to implement that. I think that we have to implement the this this thing in our package. And maybe at a package level, but I want it to be reusable by other tools, depending on our package, like a Reddit package or also Santa Santa's package. See, because it's pretty much it would be pretty much the same. Yeah. But I don't see it's very specific to Fedora. But no, no, no, well, you know, five or six are always going to be difficult. But yeah, yeah, yeah, I'm speaking of future. To me, Santa six is already too old. But but I don't want to make it mandatory. So if people don't use it, it won't bother them. So anyway, but we have this, we also have to see with per girl how it's going. We need to have some namespaces for packaging and managing patches. I tell you the way I do packages work is that it registers three remotes, the origin, which is this kit, the patch, the patch repository and the origin of stream repository. So it fetches all these origins. And then it will it will update the patches against the upstream repository. And then it will generate the patches in part them in this kit in one comment. So it will generate a separate commit. And then you and then you do your work of packaging. Oh, there is a very standardize change log, you may want to customize it, or maybe you want to change some option, but that's package or work. That's not the tool work. The tool will be streamlined, what could be automated, not the reverse. Also, don't forget the new hotness thing we have. Yeah, the Nietzsche and the new hotness where that's the thing that automatically files bugs that there's been a new upstream release and does builds for you. But of course, all it knows how to do is run, you know, yeah, said line. It doesn't. It doesn't know how to rebase patches and stuff. Could make it very interesting. And theoretically, it could commit the stuff on a branch and say your package is ready, you know, and merge branch and push. And if we had reliable CI, we can even imagine in some cases it goes directly to repository. Well, we do sort of. I mean, I'll say works. Yeah, but it's to me, well, I'm kind of continuous iteration pedantic person. So if the CI is not comprehensive, I prefer to have some more testing. So but if we had, we feel we had that we could generate package that installs, deploy it and then it could be tested out against states cases. And it was why not going to the repository? Anyway, that's what testing is for testing things. So can you walk me through? Yeah. Let's say I have package a. We'll save that for a different discussion. So I have tar model and patch. What would be European in the proper steps? I think that if you we would need some kind of convention to tell in this kid that your your package will be managed through the gateway. So for instance, we could have a file which said set the flag and what you do that package new sources, uploading source to local site catch. You would be telling, okay, this package is managing it. So I will upload the table and then automatically untag the table and version it into the source repository. That's how Debian works, actually. Well, not all groups of Debian, but I've been contributed to Debian science and most of the packages manage it and by gate and most of scientific package have no upstream gate repository. So basically all you're taking is extracting the table initially. So you will be Korean repository. The next time you will be it will recognize the commit created by the extraction of the table and recognize the patches and then it will extract the new table, create a new commit and rebase the patches on top of that. So if a fail, you have to fix it yourself. You always have to resolve conflicts. So yeah. Well, when it goes up there, it will tell you these packages fail? Yeah, I think that in first time, it will try it locally and then upload it. And if there are conflicts, you have to solve it by hand. I understand that this kind of workflow being not usual to everyone. We need to discuss it and explain because even for myself, it was a bit confusing the first time I tried it. Okay. But it makes sense after I tried it. So what's yeah. So keep the same to replace patches because it knows the history. Yeah. And say Yeah, but you lose the functionality of testing if a patch has been already applied to absorb sources. But that's the sad thing. But at least you do you do it the way the easy rebasing and also you'd be able to track the changes of sources. You could say, Oh, I could generate a diff of the new and old sources. We could add new features if we had kids to manage our sources upstream and a patches. And well, the problem is that we could do a lot of things. But the tooling actually is not here. But that's, that's how are you here? We are here to think about ahead of what we'd be doing and then implement the touring to do things. For instance, one of the interesting things is that we're having the project called review server. And until last year, it was just a project on few slides. There was no code, nothing. Just people saying, Oh, okay, the current review process is a bit cumbersome because we use bugzilla, which is not usable for that. We built a process which is, which is in my own sense for workflow wise, pretty sane, but the implementation sucks. So people say, Okay, we will be re implementing the same workflow, but in an adequate tool, which is federal review server and then we'll ship it. But it didn't exist last year. And Pierre and only remember his nickname. I'm sorry. Yeah. Yeah, the problem is that I when I remember his nickname. Oh, yeah, Stanislas. Yeah. Yeah. Yeah, it's okay. Yeah. If you see us Stanislas, but it didn't exist last year, but they presented the project and I actually made sense of people started working on it. And we even have a Google some of card working on the review server. Well, it's not quite ready, but it's moving forward. And I hope by next block, we would be able to have it in production or at least in staging steps. So people could be able to test it and see if it works. And it would solve so many problems, but we didn't predict it when we were last year in that flock. For instance, Oh, checking if there are duplicate reviews. Nobody spoke about that ever. But now there is a future in federal review server. But when you submit a review, we'll check if there is a there isn't a review already suggested proposed for this package. We've been using bugzilla for that forever, but it is really not right to. Yeah, too slow and it's horrible. I mean, even if it was fast, it still wouldn't make any difference. It's just the wrong format for that. Everybody needs to pile on comments. There needs to be a repository of something where people can suggest without me going through and writing the review writing the package for the guy. Exactly. And the more excited thing is that we would be able to collaborate on reviews. Actually, it's kind of the mentor and the review relation, which is not good because, okay, it's fine for a new package because that's the way I've learned. But when you have an experienced package, why not helping him in getting his review ready? Because we'd go so much faster and we'd decrease the queue and we could focus more time on the reviews that need more more eyeballs or helping new packages getting in because I don't want to do the the word for new package for a single reason. I want them to learn the hardware, but new the current package already, I assume that they already know that stuff. So I should be helping them and then get the package ready. And that's all we should we sometimes I have a review and I just need to check. But since you can't fix it directly, approve it because the guy would be waiting for month. Okay, nobody's answer. And it would be solved just because nobody answered it. And if someone could just come in and fix it. Oh, approve. The other thing is, I often have time to do some drive by, you know, I'll go through and it's like, Oh, that package is good, but I need to fix this thing. So but I'm not going to spend the time to type up the entire thing and go through all of this when there's really no point in me doing it. Yeah. Whereas I could just get it that much closer to being done. And at least something would happen. Yeah. And the problem is that when it's nitpick, sometimes when I try the package, I just tell him fix it that important time. But I don't like it because I would prefer it to be fixed because I'm not if I trust the person. I'm not even in my case. I'm not sure he will do it. But I don't maybe not have the time to check everyone. But when I try the person, okay, I trust you. But sometimes I don't know the person. So I prefer him to fix it. And well, if he's in package group, I would assume that if I fix it, he will apply it. So on the flip side, submit a package and somebody has a nitpick. Yeah. I like it when they say, Okay, fix this. I approve. But please fix it. Yeah. They have a nitpick like spelling or spelling to me is not blocked. Okay. And like, you submit it in my thing, like a day and then a month goes by. And I'm like, Yeah, I mean, you got it able, but nobody did. And I can't do it. Then I can't a couple of months goes by. And then I gotta put it in the new version. Oh, yeah. I'm sorry. I mean, because honestly, I'm responsible for a lot of it too. Yeah, sometimes I'll just go through. Yeah, there's 1000 packages in there right now. And I'll, you know, I'll paint it all of them and then take three months. And the problem is that some people ping you to for reviews. Okay. Okay, I will help you. But did you make some informal reviews? Okay, start by that. Right. Because the problem is that, okay, people don't do it. That's another topic on this. Yeah, but let's keep on. We are between packages. So but the problem is that if you want the queue to decrease help, I say even informal review help because when you tell explain someone that he's some doing something wrong, he will fix it. And when someone wants to do the formal review, that's work saved later. So just do informal reviews. Yeah, as long as the package is closer to being done. Exactly. If you look at the stats from the keynote, people have just jumped into copper and you're not even bothered. And that's, that's dangerous because that's the problem we're so you're right, you're going to do this review server. We're going to make it easier to maintain these things in a proper way. Yeah. I think that for instance, we have this tag called federal need sponsor, which would have just a checkbox. Okay, this guy is not in the package group, it should go the full way. Yes. And the other guy, okay, out of any package or proven package to submit the access or at least submit pull requests and work together. But we need actually to simplify the process, not by lowering the quality, but allowing more collaboration. That's the way. Yeah, it doesn't have to say. Yeah, I love it. It's already gone through like the review thing. Well, the other the other important thing about all of this is we still have this emphasis on it's your package. Because you submitted it and you're going to maintain it. Because all of the work for the review to getting the package into shape is on one person, which is a submitter. Yeah. When but all of a sudden it's supposed to become the community's business as soon as it gets in, even though that rarely happens. But if it was the community's business, as soon as it was submitted, you don't have to change the culture as soon as somebody clicks the button and says, Okay, now it's a community package. Exactly. That's even one of the problem. But you can change the reporter and or SCM script. Sometimes check with the reporter because if you do the CSC requests, but you're not a reporter, the script will fail. So you have to redo to open a new ticket. Well, you don't have to fix it. Yeah, we can fix it. But actually, that's not the priority. So that's annoying. I just had the case last night. Oh, I submitted this review start for two years. Okay, I think the package. Okay. Uh, the process actually is that you close the ticket or because the ticket to be closed as tall and start a new one. Oh, I'm losing time. Well, I can do otherwise because well, especially when you have to wait 10 minutes for bugzilla to answer and I will apologize because I actually wrote that code that you're complaining about. But um, there was there's no I mean, you can ignore it, but there's no real easy way to bugzilla doesn't let you change that. Just really the wrong tool for the job. But yeah, actually, I understand it as a sanity check because you want to be sure that nobody else is doing this and some requests. But but since we can share the reporter, that's how bugzilla is made. And it makes sense for the tracker. Yes. But if you're tracker, it's completely different. We want to be able to swap the review because okay, it's you, you, you know, you're not you don't have time to take to do the process. Okay, let someone else do it. And anywhere we could add you later as owner of code maintenance. So we don't care who is leading the process, actually. But that's the problem. We need to fix the tuning and find the things that people when we had that's recurring deal, every time we speak about improving the process, they just are saying, we should draw guidelines, we should a little better. And that's not the right way to stand that. That's from an FPC perspective. Everybody says, Well, you should tell people how to do it. But we can't. I mean, the document would be 1000 pages long. And you still have questions that come up there. And you have to allow for common sense. And you have to allow for people to disagree. We have to make a choice. Do you want quality or not? So I think that we should improve collaboration. And in the few cases where we can do it for like Chrome, maybe we should have it on the site as actually an improve integration from third party project. For instance, copper is very lightweight. Maybe we could improve copper to be something that is as good as Koji and the federal system and make and say to people, okay, we recommend such repository because we know the people maintaining them are trusted. For instance, the big data is having issues because they have a lot of bundling libraries. And if you had to agree through to the world process, it would be impossible. But even then agreed that we shouldn't be pushing such package into federal. But they have no way to do it on the side and say, okay, we are the federal that they see. It was I was proposing them to until until we fix the situation to how to maintain a copper repository on the side. Because we that's awful. I've been helping the people maintaining adult and they are doing an awesome job in unbundling libraries. But it changes every minor releases. It's impossible. And at some point, either we say, okay, we want you a white card for a limited set of package. But the problem is that if we start doing that, many people will be asking. So I don't know, maybe we I think that if we are doing that, it should be only on strategic thing. For instance, let's say the concepts say, okay, we consider big data strategic. So we will let the technical community to define the limited set of package, which are load or not. Or the other way would be, okay, go on copper. We will adversize our repo as a semi official repo. But that's not in federal. That's on the site, beside federal. Because that's the only way. Or if we allowed to push package package with as much bundle and library would be encouraging people to do it. And many people are sneaking already package with bundle libraries. We've had checking the current exception. Yeah, it's hard to find. Yeah, so usually what's what's I try. So our instance is to see, okay, this is the library that are already a load. Because like JavaScript, which is hellish for the moment, the popular libraries are, I have an exception. Most people don't know it. So they don't bother. So I told them, okay, if you are using such libraries, you can do it, but mention it. Right. But when it's a C library, a bundle C library, it's very easy to bother it. So do it. Okay, it may require some work, but that's still easy compared to JVAR. And I know that with Ruby, you should have a hard time with bundle libraries. Actually, it's not a matter. It's kind of a lot, I mean. I did run into them. My team does work on the OpenShift team. They say, oh, put this into our stuff and Fedora. And I put it into our stuff. And then I went, oh, well, here's the small, big, small vendor. I don't think they have a funnel in it. They put it under vendor. And do you know that that's how much of Fedora? Yeah. And the problem, we need to have consistent guidelines. And the problem is that people on the main list often don't understand that people are not closing the discussion. People, you just have to find another path to reach your goal. Because most of the time, the goal is agreed by everyone. Okay, we need to simplify reviews, but how? That's the problem. And people, when you say no this way, they don't understand no at all, which is not the case. And I know, for instance, people are frightened of the FPC because they say no. But well, have you spent time reading logs and understanding the point of view? Because what I'm saying is that they need more input for you from you or you fix something. You're talking about the recent, whatever that kitware code was, I forgot not ready. But yeah, it's like, somebody says, we want to bundle this. They didn't say why. Yeah, it's okay, but you know