 Okay, so this talk will be about what's new in the land of RedisMonitoring.org, the 2022 edition. My name is Michal Koneczny, I'm a senior software engineer in CP team. Maybe some of you are asking why I have the wizard hat and why this is all doing in a magical way. I started to work on the RedisMonitoring.org a few years ago and I actually did a blog post and the blog posts are written as a magical one. So if you want to read them, they are on a federal community blog post, so feel free to read them. I didn't do any in a long time, which I should probably fix. And let's get to the presentation then. Okay, so first, so you can see this is a vision of the magical world of RedisMonitoring.org. I'm on the mountain here, so I can just bring you this whole picture. I'm usually on the castle and the highest ever in the castle on the image. And the new hotness that is a part of RedisMonitoring.org is floating somewhere above. Okay, so some basic sorcery, so you know what this is about. Okay, so what is RedisMonitoring.org? It contains from two applications, at least in Federal. The Anitya is web interface. It's actually what you will see when you visit the RedisMonitoring.org page. It allows users to add project which for new releases, it automatically checks for new releases, it sends federal messages when new version is retrieved. It allows you to actually work with the database of the Anitya. And the second one is the new hotness, which is the federal messaging consumer. And this one is what you will get as a package or notifications about a new version. It consumes the messages from Anitya and creates the bugzilla for you. And even starts a scratch build if this is configured. And first look at the Anitya. The Anitya has some magic numbers, some statistics, everybody loves statistics. So let me ask you a question first. How many projects do you think Anitya is watching right now? Let's be honest and not check the page itself. But yeah, just throw your tip in the chat. I will look at it in a minute. Just first look at the contributions from the last nest. So what you can see in the parenthesis is what was the contribution in the last year or statistics from the last year and what happened from the last nest till this nest. They are probably some things missing because there was some new commits incoming in the last few days, which I didn't have here, but otherwise it is here. So we had only two releases for Anitya instead of eight, but oh yeah, somebody is confused about the year. What is in the parenthesis is from the nest 2020 to nest 2021. And contribution from nest 2021 till nest 2022 are those that are before it. So first we had only two releases. This is much less than the eight in the previous year. It was because there is some issue with the authentication. I waited long time till this will be solved on the upstream, but it didn't. So I created a workaround and it's no running in the Fedora ecosystem with the workaround. So if you try to run it on your own machine, you will probably see issues with the authentication. Okay, so we had many more commits from more contributors. The number of commits could be somewhat messed up because I enabled the PENDA board, which is automatically updating packages and creating pull requests for them. So this could be most of the commits that you can see, but I still think that we have plenty more contributors than we had in previous year. So issues created, there were much less issues because there wasn't that much releases. So I think this is the reason I didn't have that much time to work on it. So there were only half of the issues closed in the previous year. And the current version right now is 1.41, which had a bad issue in 1.40, which caused the database to actually keep the Anitya to keep connections open to the database. So we had plenty of connections just for the Anitya itself. So and now I will look at what the people thinks about the number of packages. So as I see the numbers there are really low, you will see it now. As you can see, the Anitya is currently watching over 200,000 packages, which is 30,000 more than last year. And for Fedora mapped packages, we have almost 21,000, and we had 20,000 last year. So this is growing as well. OK, so what about new features? OK, so new features in Anitya. There are some links added to Alma Linux package. So if there is any mapping to Alma Linux package, it will automatically add a link to it. And you can click it and see where the package is hosted. We have a new backend to retrieve Git tags for Sourceforge. We have new versioning schemes. So if you have package from PyPy and it's using the PEP 440 versioning scheme, you can just select it. We had plenty of bug fixes and development changes in the release, especially the wine point 4.0. And the Fedora messaging schema was migrated to separate repository. This will help us with managing the versions of the message schema better than when it is part of the Anitya repository. OK, and what about the future? So one of the things, these are the issues I think are interesting. And I would like to see them in Anitya in the future. First is the replacement rules for version strings. It would be really nice to actually have some rules you can specify that will just take the version that you receive from the upstream. And just put it in some format that is more readable. Because sometimes the tags on some of the projects doesn't really look like a version. But yeah, people are tagging plenty of things. So it's always some issues. So having some rules that you can actually set would be nice. Right now it's done by just if you want to actually do some rules, there is a custom backend. That will allow you to actually use regex, that will parse the web page, which is not really great. And it's not that quick like using the GitHub API. But yeah, it's working. And for some projects, it's only way to actually get the correct version. Because the version that is tagged is something that isn't really a version. So yeah, it helps, hopefully. Next thing I think is support for different version streams. This is just for projects that have multiple version streams like 1.0 something, 1.0 something, 2.0 something, 3.0 something. So this will allow you to actually set up things that you will set up for the project like version scheme for different version streams. It will allow you to actually address some changes in the projects like switching from semantic versioning to calendar versioning and things like this. So you will just have an option to actually say from these versions on, it will be calendar versioning and it will work. It will be sorted as a calendar versioning. And even you will see that there is a new version in 1.0 something and even when the 2.0 is out, it will be useful. And right now, and the next things we have is the links for distro mappings. This is something that somebody from the community actually came up with and wanted us to edit. First, it was for Fedora, then I think Alma Linux was the second one and there is the third one as well. And we want to make this configurable. So there will be always some distro and what link it should point to with the name of the package as some variable that will be added. We will have new authentication back again. This is needed because the current one is not working without the workaround. Hopefully the new one will have support for Google and GitHub. We already have some work done in this case, but it's missing the Fedora sign-in, but the Google and GitHub are working as I saw. But yeah, it's still not merged. It's still working in progress. And the next thing I would like is to have RSS feeds for projects. So you don't need to have your own consumer for Fedora messages to actually consume Anita updates. You will just see the RSS feed that will just tell you that there is a new version in Anita. And the next thing I have here is to have automatic filling for project details when creating a new project. So if you, for example, have some Python project, you will put a name, you will put that is on a PyPy and it will just take all the other things or some same defaults, just fill in and you will change what you need. Okay, so this is all for the for the Anita and now to the new hotness, the floating island in the realm of magic and the new hotness, some magic numbers, same as on the Anita, we had more RSS on the new hotness. I actually spent more time with the new hotness and with Anita this last year. We have plenty more commits, but as I said, this is, this is because I enabled the dependable and most of the commits are from the dependable. We have less contributors, which is not bad, but it would be better if the number will be growing. There were much more issues created. This is because the bugzilla notification, no contains, if there is any error happening, you will get a link to the new hotness issue tracker. So you can, you can file the issue directly and plenty of issues closed more than it was created. So I think this is a good base in this. So the current version is no wine point to wine one and in the last year it was 0.13.4. So we finally get to the version wine point zero and we continued. Okay, so new features. So for new hotness, we have some new features that are good for anybody who actually wants to consume the messages. It currently can work with multiple versions notified at once. You may be noticed that some of the notifications on bugzilla, no contains releases that will, versions that were obtained from a risk monitoring and version that is considered lightest. It will only right now it will only notify you if the latest is changed if it's newer than what it's in Fedora, but it will, it will also make you know that there were other versions that were together with it. There is a support for stable versions only. Only works if the anitya actually has is the project on anitya is set up correctly and the versions are correct. So it can recognize what is the stable and stable version. Currently the stable versions are this isn't configurable into this kit yet. There is a pull request for this kit and pagur, but they need to be merged first before this will be available for anybody to actually check it. There will be new options, one for the stable versions only and one for any version. If you want to actually be notified about any new version that will be, that will be retrieved by anitya, you can, you will have the option. But this could cost that the version that are retrieved again will be again notified to you because if there will be any admin change in anitya like deleting some version and retrieving it again, it will, it will notify you again. Next thing I said is the bug seal identification was actually rewritten and now it contains even the link to monitoring settings. So you can click on it and just change that you don't want to monitor, don't want the monitoring to actually watch your project or you can change it to any other option you want. The documentation was updated, it was updated to a state when it should be much easier, much more easy for anybody who wants to deploy it, deploy it and for anybody who wants to use it where you can actually find information how you can set the monitoring and other things. And same as anitya, we moved the federal messaging message scheme to separate repository which will help us to actually maintain the versions for it much better. Because if it were in the same repository, it would actually cost some issues because if you do a release on GitHub, you will do the release for the main project. And if there is any change in the messaging scheme, you will actually see it only in the tag or another place but not in the release, only maybe as I mentioned in the change log. Okay, so what is the future? So future for the new hotness, we want support for flood packs, we want support for federal modules, we want support for Apple. All of those are change that needs to be actually working with another, in most cases it will be just working in another namespace. But I'm not sure right now and we will need to have different distribution in this case. It will be still Fedora, but it will be Fedora flood packs so we know that this is actually a flood pack and we can actually address it. And the last thing that is actually in work for a long time is creating the poor requests in this gate. This is still work in progress. This is still work in progress and I can't do much about it because it's no waiting for some change in Pagur which wasn't deployed. It was merged but it wasn't deployed yet. So I'm still waiting for it. Okay, and this is all I have so I will look at the questions. I see one in the chat. I see one in the chat so I will look at it and then I will check the Q&A. What would need to be changed to for it work with Apple? So I noticed that there is a Fedora Apple distribution in Anitya already so this is solved. But on the new hotness I need to actually check currently checking only if the destroy Fedora. If it will be Fedora Apple we need to have another branch in the new hotness or part of code that will actually change it to work with another namespace. I'm not sure how for Apple are the scratch builds actually run. So if I can just use the same code as for a Fedora or I need to change something in Apple I need to look at it more closely. But yeah, it could be possible to actually check Apple for lightest version and compare to Apple. It is possible. Okay, so let's check the questions. There is one that is uploaded. Bank able to prune versions without filling a bug would be nice too. Yeah, we don't really want the users to actually delete the version on their own. But yeah, we could probably do it because right now it's only admin, admins can do it. So if you have admin rights and there are possibly to fill a flag. I know that the flags are not, I'm not really responding to them and they are not really visible to the admins, which is something I need to address. But I'm, I'm thinking if this will be actually a issue to actually let people, the users of the Anita to actually delete the version because all of the versions will be retrieved. Next time there is a new check. So yeah, I need to think about it. Okay, let me see what other questions are there. Sometimes projects go back with release numbers. So basically they release a version font that it was mistake and take it back. Some point Anita would ignore future releases after this pushback. Yeah, this is, this is based on the versioning scheme you set up. If the version is considered newer than the versioning than the last one, it will stay. This is something that right now needs to be addressed by admin actually delete the bogus version and then the versioning will be fine again. But there isn't any, anything that could automatically do this because we are not checking the versions retrospectively just looking for the new one that we don't have. I'm not sure if it's even a good, good thing to removing versions that we don't find because for some backends, it's, it's retrieving. It's just parsing the page and if the page only contains the latest version, it will delete all the others. Okay, so next one. Would it make sense to support the finding or a lot to watch in spec file or in a file in this kit? Right now, we are having the Anita independent of anything that is in Fedora, right, Fedora word itself. So we don't want it to really check this kit or other things like it. This is a new hotness thing. The new hotness could do it, but it is just for, it is not, not really great because it's not checking for the new version. Anita does this and you actually need to set this up in Anita project correctly. Okay, so next one. I would love to have release monitoring enabled by default for our new Fedora. What would be needed to make that work? In particular, would Anita be able to figure out automatically Rust full is Rust package listed in on crates IO with semantic versioning and summary for Python. Oh, this is something that is actually, that is actually in work by, by Terra lunch. I am not sure I'm thinking it's instilling progress. It will be opt in the people don't need to, don't actually need to have been notified. Not everybody wants the notification for a new package for a new version. So it will be opt in, but right now you can actually specify when you're creating a new package if you want to be monitored or not, but it doesn't create the project in Anita. This is something that we want to add and it's still in work. It's not there yet, but it's something we want to do as well. And the last one can package maintainers be given some level of control over the packages on release monitoring.org. For example, some upstream publish a ton of messy versions before a Fedora package is created. Sometimes messing up incremental versioning I'd be great. We could clean that up yourself and add the proper exclusion rules. The exclusion rules are actually something that you can do by yourself. You don't need to, you don't need admin of release monitoring.org for this. The deleting of the version, as I said before, we didn't give users ability to actually delete the versions. The reason for this was actually to preserve as much as possible and only the admins have the possibility to do this. But when I'm thinking about it, maybe adding this possibility to standard user of release monitoring.org could be possible. They still can't delete the project, but they could probably delete the versions only, which would help them to actually manage the projects. I assume they will be throws that will just delete all the versions on the project. But yeah, if they are throws, they can play with the release monitoring.org right now because there are plenty of things you can do. And that will, because everybody can edit any project. So if you want to just exclude all the versions that no version will be retrieved in the future, it's possible. But I don't think I don't saw anybody actually messing up with this and the people could actually save, set it back again by themselves. But the exclusion is already available. There is exclude versions or I'm not sure how it's like now called, but it could be like this. Okay, and for the package maintainers actually managing it, as I said before, release monitoring.org doesn't know anything about this kit in Fedora. So it doesn't know who the maintainer of any package is. They don't want to have this because the package could be for plenty of distributions and we don't want somebody to actually have more rights than the others from the different distributions. So either we give the rights to all users or some of them will be only for admins. Okay, so this is all I have for today. There are some references I will, I can share the link to the slides. Let me just share it and otherwise this is all for me. Thank you all. There is the link. Thank you all and see you later on the nest. Bye everyone.