 First thing I want to introduce myself, my name is Michal Koneczny, I'm a mage in the CP team and I'm taking care of the magic land of the release monitoring org. I must apologize for the wizard hat, I usually have it, but right now I have some issues with it, so I apologize. Okay, so here you can see how the world of the release monitoring org looks. I'm usually looking for everything from the highest tower in the castle, part of it is also the island of the new hotness, which is not seen on this image, but yeah, it is there. So you can see it's pretty nice world. And here it's some basic sorcery, so everybody is kind of knows what release monitoring org is. It's actually have two parts. The one part is Anitya. The Anitya is most of the magic realm you actually saw. It is taking care of checking for the new versions of projects. It allows users to add projects they want to add. It sends federal messages where there are new versions. It is more similar to services that are looking for the new versions of projects. But in this case, it allows users to specify their customs projects. They could use their, they could add almost everything that has some project page and there is anything you could, any page you could check for new version. The second part is the island of the new hotness, which is only used in the Fedora itself. It is Fedora messaging consumer that is listening to the messages emitted by Anitya. And if you ever as a packages get notification about the release monitoring client new version, it was created by the new hotness. It also can start a scratch build if you would configure this for your package. Okay, so let's go. So first we will talk about Anitya. This is a realm of magic that is really nice and fun. And as every other wizard mage, I like the numbers. So here we have some statistics from the last vlog. I tried to find everything that I could that could be considered interesting. From the last vlog we had four releases of Anitya. Most of them are only minor version. There is my release on the way right now. We had 117 commits from seven different contributors. Thanks to everyone who helped with it. We had 68 new issues and closed 75, which is nice because we are actually keeping with the base and closing the issues quickly. There are still around 100 issues open on the Anitya right now. The current version is 0.18.0, which is the latest one and there are some issues that need to be addressed, but today will be addressed in the next release. There are a number of projects that are watched by the release monitoring are currently 110,447. We have 17,607 of those projects mapped to Fedora packages, so this is really nice. There are plenty of projects created by some automation that was added that is actually sending to libraries.io, which is trying to catch the PyPy and RubyChamp projects and creating new projects for them automatically. Okay, and now we have new features. What goblins delivered? We have plenty of goblins that are working as you could see in the last slide. There were seven people that were working on this, so pretty nice. And what we add? There is support for multiple version prefixes. If you ever had issues with having the versions that had different prefixes and you could only remove one, which is only removed from the Anitya page, the prefix is still there. We now have support for multiple prefixes, so you could actually remove the prefixes from every version you need. The next one is the checking for new versions, only if there is any change on the URL. We use that if it is modified or the header is something similar, I'm not sure right now, which is asking the page if it was modified from the last time we visited it. If not, we will actually not get the full page and not parse it. Just do this. Hello fetching releases, before we only release the tags and the tags sometimes contain bogus versions or just some things that people wanted to tag and not actual releases. So we added this option to fetch the releases. It's still fetching the tag that is for the release, but it's using the release's GitHub releases page for checking this. We add the calendar and semantic versioning because the versions are not sorted by the order we get it, but they are sorted by the Anitya itself. So now you can choose by RPM versioning, semantic versioning and calendar versioning. All of these are working and there shouldn't be an issue. But there is issue with the projects that are changing the versioning in the lifetime, but this is something that is hard to address and not really solved for some projects. Next one is there is automation for deleting projects that didn't have any versions. And there is error threshold that if they reach this error threshold, which means that we had the checking for the new versions. And if those versions, if we can get those new versions, it means that the page is not available, the projects is actually abandoned and there is no page for it. Or there was some other error and there are 100 errors in row, we delete the projects. But there is one bug that is known that for the GitHub, if there is no new release, it's considered as failed check, which is bad. And because of this, this feature is now disabled on the releasemonitoring.org. It will be introduced again with the next release, which is fixing this issue. I started with this because there was plenty of bogus projects from libraries.io that was created in PyPy, but was only for testing or something like this. There was no version on it. The project didn't even exist for a few minutes, so this was why I introduced this. It deleted plenty of projects that were failure, but some of the people actually found that it is deleting their project that was configured correctly. And it was because of the GitHub issue. Okay, the next one is the one that introduced the issue with the GitHub. We are trying to store and use the latest known version cursor. So if we are checking for the new version, we don't retrieve all the tags that are on the projects. But we are only trying to get the new ones that are newer, which is considered by the cursor, which is on every tag. This cursor is used to only retrieve new tags or new releases after this. So it's actually helping us with the rate limit on the GitHub. But it actually introduced the error with the GitHub failing when it was not receiving any version. Because in the past it was considered as fail when we didn't retrieve any version. It meant that we couldn't contact the project with the issue. But yeah, it's happened. And the last is the timeout option for check services. So we don't get stuck when checking for new. Okay, so right now we are working on the milestone 1.0. Oh, okay, at the GitHub thing. Oh, okay, I will get there for the last thing. Okay, so there is a timeout option for the check service, which is helping with the check service being stuck. We had some issue with this before and I started to actually address this and timeout is helping. Okay, so the current situation. We are working on the 1.0 milestone. We have a few things done. There are a few that are left. What is done is option to archive projects. So if you now have projects that is currently not being maintained upstream or there is some other issue, you could actually take it as archive. If you archive it, it means that it's not editable. It will not be checked for a new version, but it's still in the Fedora inter-release monitoring.org and you still can look at it. So it will not be deleted from Anitya, but it will be, it will not be checked for a new version. This will help with the projects that are currently checked and failing because the upstream is no longer, no longer exist. Or we can actually parse the versions because there is some other issue. I will remove more version at once. If you were administrator of Anitya and somebody wanted to remove some version, they obtained it by error or just tried something. You need to delete them one by one, which is no longer a thing. You could now remove all of them and just do a new check and only the correct ones. The other thing is to separate stable and unstable releases because till now Anitya actually get every version and every version was considered stable. Even if there was a method for the versioning to actually mark the releases as pre-release or unstable. So it will add a new thing to the message that is emitted with the version and there will be two new arrays. One will have the new version, the stable version and one will have the unstable versions. I plan to add this to the new hotness to work with it and actually for those who are interested only in stable versions to have option monitor only stable versions. So you will not be bothered by some alpha, beta or something like this. The next one is to fix for the github issue where there is no new version on the github again, it's considered as error. This is actually pretty bad because it was introduced with the cursor because the cursor is actually marking the tag. And we are only receiving what is at after the tag and if we don't receive anything, we just consider it that we weren't successful to retrieve the versions at all. So yeah, this was an issue and it's currently why we disabled the automatic deletion of projects. What's left for the milestone 1.0 is to report multiple versions at once and remove the message write things and add preview mode which will allow you to try your things, your changes before saving it and just doing the check in the actual database. I hope this will be, this will not be that hard to implement. Okay, next slide. The new hotness, the new hotness is floating island in the realm of magic. It's actually the nice island. It doesn't have to, it not study robust as Anita, but it still does it does what needs to be done. Some, quickly some statistics, there were three new releases, 44 commits from seven different contributors. 10 issues created because most of the issue for the new hotness is actually is actually open it in the anica because it's really smart doing good org and there is not much people that know that there is a new hotness in the back of it. We closed 22, which is nice because we are actually closing the backlog and the current version is zero three 13 zero. Okay. New things. Monitoring status relatively from this kid. So you could know configure intersorts budget federal project.org you for the package if you want to be monitored or not. And the new hotness is taking this directly from pagore. Refactor config to center is a default. This were more a refactoring thing when we wanted to have configuration on one place and not in every script, not every source code and plenty of back fixes. There weren't new that new features because the new hotness is actually pretty simple. Okay. Okay. So current situation. I'm trying to create a milestone wine point zero. Same as for an idea. What is done I add a tone carrier to generate the change looks more easily and automatically. There was one issue when the when loading sources, which was not that which didn't break the new hotness but it was an issue. What's left. What I want to have in wine point zero is to file PR instead of touching page to bugzilla. It will file PR directly against the source repo. This is done by the ogre, which is the library that the packet project is using. Because there is no staging environment right now, I can't work on it anymore because it needs to have access to testing bugzilla and this kid and other things. So it's not that easy to test. I want to have a value locked when error happens during the comparing of sources because it will at least say if the sources are not the same. Or we had some issue that was that could be solved by this if this was in the in the actual lock. Refactoring of sorts using clean architecture design. This is something I want to personally have inside. And the clean architecture should make the new hotness much more maintainable and it's small project to actually work with it. I have a design created for it design document but didn't do any work on actual refactoring. Working with federal messages containing multiple releases. This is the same as I were talking about the stable and unstable releases for the. For the. For the Anita, so it will actually work with more versions at once discovered by Anita and it will not just. It will not just work with the latest. There are some projects that want to want to have. Even the old versions because if there are. If there are streams like four point or four or three point and you got the version three point something. It's actually not emitted by Anita because it is considered old version. Or it's it's it's emitted by Anita if there is no, no newer, no newer version. But the new hotness is skipping this because it's older than to be what he have in in your repositories, which is not good for some projects. And the last thing is handle temporary errors more gracefully right now the new hotness is running in open shift and every time. Every time we had a temporary error, which is a bugsy lies not reachable or something like this, the crash and just started again, which is not really great. And I want to handle it more gracefully and just want to college the message and good and do it do the same again later. Okay, so we are at the end. So I hope you liked the. The presentation and do you have any questions. I don't see anything in chat. Luna. I see that the, yeah, I actually had this talk at the last vlog so I trying to talk about it more. Integration with pocket I will use part of the pocket. But it was only only the ogre library. I have some vision in the future, which I'm not sure if ever be true is making the Anita part of the part of the package of workflow. So if you create a new package in Fedora, you will actually get automatically project in Anita that will take care of fetching for new version. Not about not any equation with packet but could be at least we will create a patch for the for the project and create a PR on the source kit. So I think it will be at least easier for everyone. Okay, the zero zeros at the start are because when I took over it, it was zero point something. And I just, I just did the same for the for the time being and decided decided few months ago to be sure that I should actually create create 1.0. Because I think the project is major enough. I see your time is is full. So, yeah, we don't have much much time. So, thanks everyone for attending. And I will go for another talk that I want to see.