 Are you ready to enter the amazing world of releasemonitoring.org? I will be your guide, Michal Konečny. If it's too hard for you to pronounce, just call me Michael. I'm a wizard from the realm of releasemonitoring.org. For those of you who don't know what releasemonitoring.org does, it's actually taking the news from the outside world and trying to notify the gatekeepers of the packages in Fedora. So, I will move with you through the future of this amazing world. So, first, what awaits us and what is covered by the mists of the future. Okay, so this is the bright future, this is the faraway future. I hope we will get there someday, but it's too far. It's not something we will get today or in some visible future. But it looks nice, it is bright, it's taking everything. And this is what it should contain. It actually should be a future that is more friendly to the user. It's more reliable than it is right now. It should have plenty of features. It should write creating PRs instead of notifying on Baxilla. It should have automatic recognition of project from URL. You just give the URL of the project and it will actually fill the project in the releasemonitoring for you. Creating GitHub issues for FlatHub, this is something I want personally to add, but right now, it's nothing like this in there. Reading libraries, IO, SSC, this is actually working, but it's not really reliable. Every project needs to be checked manually after getting it from Libraries IO. I want to see nice statistics for Anita and the new hotness, which are both part of the releasemonitoring.org. Anica is taking care of the projects. It's scanning for new releases of the projects. It communicates with the user, it communicates through API with some scripts. When it finds something new, it notifies the new hotness, and the new hotness is actually something that is creating right now, it's creating the notification in Baxilla. This is how it should look, so it's not the current state. One of the things is removing Baxilla entirely from the workflow. If you will get PR directly to your package, it's not really needed to notify you on the Baxilla. No, we look much closer, which is not that bright future, which is not that bright, but it's still the future we could actually achieve. First thing is the maintenance mode. This is something we are considering as a team. This should fix the most irritating issues we are facing right now. It's the GitHub rate limiting. We have around, I think, 15,000 projects on GitHub inside Anica, and the rate limit is considered to be 5,000, I'm not sure how to call it, nodes or something like this, which is depleted pretty quickly. I actually did some optimization in the last release, which is actually checking only for the projects that weren't checked before, so it's not doing, previously it was doing every project in one run. It is some sort of queue, so when the project is actually checked, it isn't checked in the next run. There are still some optimization that could be done, and still we need to do it. It means that we are checking the projects right now every hour or so, and the GitHub rate limit is resetted every hour, so you check, like, 2,000 projects, and then you hit the limit, and you actually can't check the 15,000 projects in one run. Yeah, one of the things we want to, how we want to optimize it is to create, is to add, take call it cursor, it's the cursor for the latest release, so we will continue from this release or this stack, so we will not actually get all the tags every time, because this is what is reaching the rate limit most often. Notification about more than one release at once. Right now we are notifying only about the latest release, which is not really something that some packages want. They actually have versions older. They want to get, if there are more than one update in the meantime, they want to get a notification about it, even if it's not the latest. Yeah, this is exactly what I have in mind. Creation of the preset projects, there are plenty of the preset projects, because the constraints are not really created, all to say, are bad right now. And there are, we need some normalization, because the constraint right now is set to the home page of the project, and we have two same projects, one is with home page on GitHub, one is on the home page of the project, third is using HTTP instead of HTTPS and so on. So this is something we need to address. I think this is not really used by now. I'm not really sure, because I didn't know there was something like this. Okay, I didn't know, but this actually, we have some ideas who we want to address it, and we also want to actually let the users create their own, they want to watch, because this is not only for Fedora, there are plenty of distributions that are using this. Not every of these distributions has some automation around it, but they are watching for neural disease. I got email from someone from OpenSUSE, who was interested to use it for OpenSUSE automation. It was similar to once we are using, so notify user that there is a new version of the project. The next thing is the reliability of the new hotness. The new hotness right now is working, that takes message from the Fedora messaging queue, which Fedora messaging made the new hotness more reliable, because it's actually not missing any message. But there are things like, if I hit some issue, the new hotness fails, and then tries to read the same message and fails again, so it's one of the things. The next thing is if we can't, for example, create a bugzilla issue, because there is temporary outage or something like this, we don't have any way to handle this. We actually only say that we can create and drop the message, which is not really what the user wants. So we need to figure out how to handle these temporary issues, that are only temporarily locking the mechanism, some retry mechanism or something like this. And the last one is notifications, settings, read directly from this guide. This is the line between the new hotness and pagur, because right now we have one repository on pagur, where the notification settings is set. There are plenty of users who don't know there is something like this, and in the future it's actually, in pagur it's actually implemented, but not deployed, but it's actually deployed, you will see some drop-down menu, so you can actually set your notification settings directly on this guide repository, so you will have it where you expect it. At least I hope you expect it on this place. Ok, so next one. Next one is not really bright future of the Anicha, because this is one of the optional things we are considering, because as a CP team we have plenty of applications, we are maintaining and we are taking care of. So one of the optional future is to replace Anicha directly with Libraries.io. This has some things that are pros, some cons, so yeah, it's about the consideration if this is a good approach. The pros are there will be less code base to maintain for us, which is not something that users are interested in, but it will help to make other applications we are maintaining better. The Libraries.io currently watches, I think, half a million projects, so there are plenty of projects you can actually see the updates for. What is cons is there is no authentication with FAS, but how I look at it there, only one who needs to authenticate is the one who wants to add some project to Libraries.io, which is the next issue. There is no option to add custom projects. You can't actually add any project you want, which Anitak could provide you with the custom backend, which is allowing you to actually parse any web page and look for some regular expression. In Libraries.io, they only support some known repositories, where the projects are created or maintained or developed or distributed, and only those are supported. So you actually can't add any project you want. I was surprised, I found one user is using Anitak to watch for a new version of his firmware for his laptop. He's parsing the page and looking for the regex he wants to find. So I was surprised that somebody is using this, using the Anitak like this, but it's possible. There are many of them, but most of them are historical, because the backends that Anitak support didn't have GitHub, for example, which is really big. Most of these packages are actually trying to parse GitHub, but this is not working anymore, because they changed the HTML, so you can actually use it anymore. I will look at them, most of them aren't getting a new version. And the third one is, there is no mapping to actually distribution. For artists Fedora, but I looked at Anitak and the Anitak has, I think, dirty distributions that he's watching. Some of them are not distributionary, but are used as some group that is grouping the projects that are in there. So we'll need to ask if the libraries.io will support something like this. Yeah, GitHub is there, it's supported. They have, I don't know how much, they have, I think, 15 or so the sources you can use. There is Drupal, there is Pypy, there is GitHub, there is Sourceforge, there is NPM. Yeah, there is plenty of them, but you can actually add something that is not fitting in the backends they have. The last thing is the questions. So do you want to ask something about releasemonitoring.org or about wizard or about magic? Yeah. Okay, it is visible on this one. Okay, I will repeat the question. It is, releasemonitoring is using airbasehelper or how it is work. As you can see on this slide, the Anita is actually the frontend. There is, when it's checking for the new version by running service, it's not a current job anymore. In this version, I change it to the service, so it's no much more reliable and use queues, so it's better. When it founds some new version, it notifies the new hotness. The new hotness is the backend for this. It is looking, if the version is actually not in Fedora already. It is looking on the bugzilla, if there is bugzilla created for it actually, or if it should create one. If there is, it actually doing the rebasing, so it's, or not rebasing, it's doing the RPM bump. It's pumping the version in RPM and sends the patch, attached the patch to the bugzilla issue. This is something that I want to actually make more automatic with creating directly PR in Pagur, which is work in progress. It's using packet for this. It will be, I think it will be more friendly for the users, because you will actually see in your disk repository, or your source repository, there is new version and it will actually create patch that you can merge if it's good. It's not doing any complex action, it's just updating the version. So you need to check if everything is working. If it will be combined with Fedora CI, it will be much nicer. So I need to think more about if you want to have specific version to specific branch in your disk repository to have some configuration. I'm not sure, did Tomáš, did packet try to think about it. If you have plenty of branches and you want to watch only some versions, prefix in some branches. OK, so for example, you have branches for Fedora 28, Fedora 29, Fedora 30 and you want only the major version changes to the Fedora 30 and for Fedora 29 you want to have only versions, two-point something. So if there is some kind of mapping for this, so you know where you actually want to packet to create the PR which branch. But the config is on the upstream side. So we need to think about something else because we don't have access to the upstream. So any other question? This is something in consideration so it could be removed. For now it's better to keep it because even if we are filling the PRs directly to the disk, it's better to keep the Baxila because it will be much nicer even for those who want to only watch for the Baxila updates. OK, so I should repeat the question. The question was how the GitHub rate limiting and how much it costs if you want higher rate limits and if there is a possibility to create an app that is actually watching for events. OK, so I didn't look at the coast because most of the issue is on the Anidya side because we are checking every project from the batching to end so we are just taking too much. When we do the optimization and we still hit the rate limiting we will ask about it. I think the CentroCI actually had similar issue with hitting the rate limit. I need to ask someone from the CentroCI team. I'm not sure if this will be doable for us because we have... I think the Anidya has 15,000 or 20,000 projects and most of them are GitHub so I'm not sure if patching for events for that much application is actually doable. But I think it will be possible to actually use libraries.io. They have SSC so you can actually watch for any new. So we have two minutes left. OK, the question is if you can use GitHub notifications for the new releases. There is issue that some projects are not doing releases. Only some of them does. So it's not really something you could count on and there are even some projects that are doing releases... No, they're not doing releases that are not stacking but having new versions. I didn't find out how to actually find out what version they have because they don't actually have anywhere listed this. But this is only one project that is working like this. It's creating new version but there is no duck, there is no release but the version is somewhere. I was surprised when I found out about this one. Otherwise, as I said, we are just trying a new approach which will allow you to actually watch for the releases instead of tacks because right now we are on checking tacks on the GitHub. Some of the projects are tagging most interesting things. Sometimes they are tagging some releases which is fine but sometimes you can find a tack that doesn't... that this looks like a mistake by someone not really tagged that should tag something. We have 5 pm so if you want to ask me anything I will be here. Thank you for... thank you for... for your attention. Here is a reference. You can look at it. It's actually my community blog posts which I am doing for the release monitoring. It's done in the... in the bizarre way. It's... it's not really a technical one or it's technical but it's in fantasy way. If you want to loud when reading blog posts then you can actually look there. So thank you.