 All right, so now it's easy. So we just, we need the project to exist somewhere. We need to tell people about it. We have to start making releases, maybe. We're probably gonna get bug reports. I don't want them, but people are probably gonna want to send them. And more importantly, users need a way to complain because everyone does that. So this gets into the harder part of a software project which is the community aspect. So when you're making an open source project, yeah, you can just post code out there but if you're not working to get the community on board, it might go unnoticed and this does happen. So when you're working on this, yeah, you need to have an actual structure around the project. In this case, it's software. So your typical directory layout and stuff like that, pick a license. I chose GitHub to put it there just because we had other projects there and were established. So that helps with visibility. Also, start demonstrating the workflow you want contributors to do. So it's really easy if you create a project on GitHub and you want other people to contribute. Well, if you own the project, you just push things to it. But try to get out of that habit. Instead, fork the repo and send yourself pull requests and review them and kind of play by your own rules. It might seem silly, but that helps paint that picture of how you want collaboration at work. I set up copper repos so that we could get automated builds. So all those tests, people would send stuff. So that was all the mechanics to get things happening. But I still need people to actually start contributing. And this is where you got to go out and start talking about the project. And anytime someone's talking about RPM diff or asking a question, what is this thing about RPM inspect? I've never heard of it. It's easy to get frustrated when you're working on a project. You're like, how can someone not know about this? I've been talking about it. Well, the fact of the matter is we all get a lot of email. There's a lot going on. We can't be aware of every single project. So instead, you can view those as opportunities to explain to people what's going on and how what you're doing, you're trying to save them time and make their life easier. So that's what I did for a couple years is every time something would come up, I would say, well, here's what I'm doing here. Oftentimes, people would be really receptive to that. Thanks for explaining it. And then that would lead to them contributing either ideas or patches. And it just kind of grew from there. My manager did ask me to reach out to Suza early on to see if they were interested in collaborating with RPM Inspects since they use RPM. And that was a very short conversation. They were absolutely 100% not interested. So I was like, okay, well, I tried. It was an odd conversation. I did try again about a year later and they were still 100% not interested. So maybe that will change at some point in the future. But yeah, just being aware and communicating, you start to sound like you're repeating yourself and you really are because not everyone is going to see all of those conversations. You're going to respond in bug reports. You're going to respond to mailing lists. You're going to use events like this to communicate, kind of give the same presentation over and over again. But that's how we learn about projects and that's how you start getting people interested in participating and contributing. And it takes a lot of work. I say it's harder than the code and it really is. And like I said, eventually you start getting people aware and they start sending pull requests. I had some surprises to me. The Java maintainers at Red Hat were really interested in proving stuff in RPM Inspects. I started getting pull requests from them. That was really kind of cool. The Anachek and Lib Abigail maintainers on the tools team were also really interested in receptive to bug reports and things like that. They even turned Anachek into Lib Anachek and gave it a public API, which was really nice. So you don't know what's going to happen until you keep communicating that. And kind of going hand in hand is marketing. This is something I'm really bad at. And it ties into that community aspect there. To me, this is really the hardest part. I know that I could be doing a better job of marketing the software and making the projects known to more people. I'm just really bad at that. I would rather stare at a core dump file than go and figure out how to make people aware of software. So this is always an area that I'm looking for help with and just ideas on how to improve it. I said I go and monitor mailing lists and bug reports and just have those individual conversations. Those are easier for me, but other projects may find it easier to do presentations, do YouTube recordings, something like that. I don't know, it really varies by project. Now, I've been working on this for a long time. It's largely in maintenance mode. It's stable, but there's still stuff to do. Documentation, number one on the list here. There's been a request, this actually came up in 2019, which was be able to extend RPM inspect with Python plugins, which I think is really cool. I have a branch that I'm working on that on, but it's not required. And just kind of going through the other RFEs and stuff like that. So it's just at this point, I think it's gonna evolve and kind of live in maintenance mode until such time as something else comes along and replaces it. All right, so yeah, summary. So what did I do that I count as a win? And I gave these little subtitles here because I thought I would get some laughs, but, you know. It's a tough crowd. All right, so the first was it's a library. So I decided to implement the core functionality in this program. I said it's a command line program, but I shifted all that into a library. And the reason is I feel like down the road, there might be a need to, or it might be a desire to use that functionality, but have a different execution front end. So by splitting this out into a library, I'm trying to kind of prepare for that possibility. The vendor data packages, this was separating out the data from the code. And there's RPM Inspect Data Fedora, RPM Inspect Data CentOS, and RPM Inspect Data Red Hat. And all those packages contain the rules. So when you run RPM Inspect, you run it according to a set of vendor rules. The biggest thing there is all of that's out of the code. And more importantly, I don't have to own it. So that's information that can be owned by the vendor and maintained separately in the program. We're doing that now for Red Hat, Fedora and CentOS. I still kind of have a hand in maintaining those packages, but there are people that also help with that. The last one here, I chose C as the implementation language. This is where I thought people would laugh, but there's a reason for that is the core functionality here relies on lib RPM, which is in C. The development and debugging tools for C are more mature than other languages. While I would have loved to explore something like Rust or another language for this project, the fact of the matter is I needed it to be done fast and be reliable and stable, and I know C well. And I don't know those languages. So I didn't wanna tack on, oh, I should also play around with another language. So I get the advantage of being able to use all these other libraries that exist in C. And I can also keep the program itself really small. All right, so fails. Documentation, so like everyone, I am saving the documentation until it's done and stable, so that means it'll never be written. What I should have been doing is the same thing I was requiring with code commits, which is I would also write the test cases that would go along with the code commits. I should have also done the documentation, the inline documentation so that I could be doing that all along. Me, I made that mistake of saying like, well, I might refactor the API a bit, so why would I write the documentation for this if it's just gonna change? But you know what? Who cares? You wrote the code, you're gonna change that, change documentation too. YAML, this is the thing I hate the most. I really wish I hadn't chosen YAML. It's a terrible config format. Initially, actually, I was using INI style files, but those are not, there's no standard for that and they're not really flexible. I'm kind of stuck with YAML. Honestly, that's established. It's in disk.get now with rpm and spec.yaml files, so I do regret that. And then I had this idea as well for profiles in the config, which really is just too complicated for people to understand. It was one of those like, oh, and I could also do this moment, so it's there, but no one really uses it. But that's just unnecessary code. I did mention INI style config files and yeah, I changed that to YAML and yeah, that was the only thing. Nothing else was wrong. Okay, so things that I still need to work on. Yes, command line option handling. If you're gonna make a command line program, try to put some thought into the command line option handling, don't just keep adding them. Like, it's easy for that to get out of hand. Look at TAR, for instance, or now GNU LS, which is nearly impossible to remember options for that. I could have better debugging output and logging and the dash K option, so RPM and spec will go and fetch builds out of Koji and all the RPMs. Dash K option was to keep the builds, but the way that's implemented is kind of backwards from what every user was expecting, but to change that now I need to do, I need to do some better marketing and communication before I just drop that change on everyone. So the fix itself is easy, but I need to think about the communication around that. So that's why I have not done that yet. Successful collaboration. So yeah, Anarchek, so Anarchek is a command. If you've used it at all from the Anabem project, it's actually really kind of cool, but it was just a command line tool and Nick had not implemented a library and I said it would really be useful if I had this as a library. And he said, oh, I can do that real quick. That's super easy. So over a weekend, he just turned it into a library, but it needed a lot of work. So the API was a bit haphazard and lacking. And I said, you don't have this, you don't have this. You redefined zero here and all this. And it was kind of funny, but he was really receptive to that. So now Anarchek has a library, which is really kind of cool. Lib Abigail does have a library, but it's written in C++ and I, yeah, so there's problems there. But it was nice that this collaboration with Anarchek was well received. People also started submitting lots of GitHub actions for CI jobs. So if you go and look at the CI jobs for our human aspect, it covers many distributions. All the Fedora, CentOS, CentOS Stream, REL is in there, Dabian, Ubuntu, Suza, Alpine, Arch, Gen2, Olmalenix, and I added free BSD just for fun. I was like, can we do that? You know, I tried in that BSD and failed at that and Mac OS 10, I haven't gotten that working. But this is just, you know, people saw that it was possible to start doing that and have been contributing things for that. So more coverage is always welcome. And also a project should be fun. And I had one developer submit a pull request that really fixed up the parser, refactored that a whole lot, which I hated the YAML parsing code that I had. And so he extended it to support JSON and DSON. And if you're familiar with DogeScript, DSON is the JSON equivalent for that. So RPE Mespect does support that. And we get config files that look like this now, which is really kind of fun. And this does work, you can add this and just get it. This is from GrubTube, by the way. So I just really, I don't know, I just think it's fun. Like someone's gonna come along and read this and think, what is going on? But yeah, this is just the kind of fun stuff that you can do with contributions when you communicate it out and stuff like that. So I kind of ran through everything really quickly because I wanted to leave time for questions because questions are always fun. So does anyone have any questions? Please have some questions. You mentioned various distros. Yeah, are they actually using RPE Mespect? I'm sorry, who? You said all these CI jobs for different distros, but are they actually using RPE Mespect for some of the processes? No, so those projects, to my knowledge, are not using RPE Mespect. They were just added to see if we could run RPE Mespect in those environments and if it would pass the test suite. Yeah, to my knowledge, no one other than Fedora, CentOS and RHEL are using RPE Mespect right now. So as one who had to use RPE MD in the past, the one thing that RPE MD gave you is the interactive ability to react to the results which is missing in RPE Mespect because of the nature of RPE Mespect being basically a batch run. Do you foresee any improvements in RPE Mespect other than basically disabling individual checks? So when you talk about the RPE MDIF reactions, you mean like the ability to wave a result? Right. Yeah, so good question. So the intent with RPE Mespect is to handle those wave actions that you would do in RPE MDIF through a local project configuration file. So yes, in this example here, you can see entire inspections are turned off because they don't really apply to Grubb 2. But in an instance where the control given to you in the config file is insufficient, I wanna treat that as a bug and say, okay, we need more fine-grained control for the rules in RPE MEN Spec config files. Now in some cases, that wave action actually needs to be handled through the vendor data package with a global rule. And that is kind of a thing that's not totally obvious and I wanna improve how that at least is documented and communicated. But that's actually the intent through RPE MDIF MDIF MDIF MDIF is you see the result that way, you modify the config file and then it'll run again. There's no plan right now to implement like a reaction interface type thing where you wave it that way. That hasn't been brought up. Yeah, perfect. Well, thank you very much, we appreciate it. Thank you, everyone. Thanks for coming to my talk. I hope to see you around. The next talks are available and starting right now, so if you are switching rooms or anywhere, but we'll get started here in just a few moments, so.