 So, welcome everyone. This is PingoSpeak. We have today the Picole in charge for Adir. He will be monitoring the chat as I talk so that I can try to focus on what I'm saying and then he can answer your question. So, what's happened in Pagar over the last year? So, I'll start with a short presentation on what Pagar is and what it does. We'll go through some of the recent features that we've made. Some of them are upstream. Some of them are discrete. We'll go through some of the road maps and IDs and some of the statistics around the projects. And then, of course, we'll have to answer them. So, I am a little bit chippy so I don't know if I should shut the only activity which I have is to turn off my camera. Well, then you won't have to, you won't see me. But it's worth your cameras already not on to me. Well, let's see if that works better then. So, I'm not sending my camera anymore so you should only hear me and see the video, the slides. Does that sound better? Yeah, you seem to be okay now. And I turned off my video so that it doesn't stress your connection. Okay, let's keep it this way then. So, Pager, for those of you who do not know, it's a Git centric Python based project hosting platforms. It's meant to host for every project, the source code of the project, if there is any. The documentation about the projects, there is a ticket trackers. And it offers the possibility of having pull requests to the source code tracker. Well, a Git repository. And these pull request allows flags, which are with for sub party toolings to integrate with this pull request. It is meant to have no locking. It is also extensible it is built in the way that you can send the team in but you can also add your own endpoints, your API endpoints, a new UI frame. It's really meant to be able to allow you to customize it to your needs. That being said, we've added a number of features upstream, which you therefore no longer have to do if you're interested to have them. One of them, which actually landed only in production this week was the boards features. So it's a very lightweight cabin boards. You can have as many boards as you like per project. Every board is linked to a specific tag. So when you add a ticket, when you tag a ticket with that tag, it will automatically be linked to the to the board. You can have different status. So there are one status is one column on the board. There is one of these studies that is set as the default one. So when you tag the ticket to the board, it will automatically end up in the default status column. You can also say that the status equals closing a ticket. And you can even specify which closed status to use when closing the ticket. So to give you some ideas on how it looks, we're actually using this on the Federa infrastructure project now. So as you can see, we have a board that's called DEV. That board, it comes with a tag DEV. It's an active board if once for project, you know, that are not that have been done or no longer relevant. And then if you click on the on the configure here, you will end up in this in this page here. Every line is a status. Every status is a column on the board itself. You can order them. You can set which one is the default you can you can pick if one is a close and the corresponding close status and then you can have a you know pretty colors because that makes things a little bit nicer. The columns you see them, you see there are basically the defaults statuses. So when you create a board, it basically has no status. You have the time to create the default status and those are the ones you're going to get with this. The default here. And on the Federa infrastructure, we have added a few tickets here, you know, to some of them are in backlog. Some of them are triage in progress in review. If you look at the same board today, you'll see that some of them are have moved to done some of them are moved to triage and so on. So it's very simple wrote and I still want to be able to see if the tickets is assigned to someone or not that in which is missing the UI here. But I'll be. It's very simple, it's very straightforward, but you know, it's a it's a body few if you like a representation for your ticket. And I think that's pretty useful. The second feature that we're going to talk about are the collaborators level. So we have three, we add three ACL so far you had the main admin. You had admins. So the main admin was just a is an admin just like the others except that he has his name on the on the front page. But it's her name in the front page actually the but so we had three levels of ACLs you had admins you had commits and you had tickets. Tickets you would just allow basically be allowed to edit tickets metadata assigned tickets to people type them and so on. Commits give you commit access to the to the main git repository the sources, as well as access to the private tickets because it's expected that if you can fix the code then you can access the private tickets and then admins have access to all the features to all the settings as well. So we've added a force level here which is called collaborative collaborators that sits between tickets and commits. And basically it gives you a commit that it gives you tickets level on the UI, and on the main git report gives you commit level, but on a specific set of branches that have been granted to you when you've been added to the project as a collaborator. It uses button matching. So you can give, you know, you can give someone access to everything that is starting every branch starting with features slash something features slash is also going to be accepted by the way. If you grant someone access to EPL star, or you'll get access to everything, including the EPL branch. And so on. So and you can also just, you know, praying, put the branch food and then they only have access to the exact branch food and not full star something and so on. So that gives us a little bit more flexibility on adding people to project, including in this git. So in this case, this is a screenshot on how it looks. You just go to the add user to the project for your settings you click on the drop down you set collaborators and he's going to ask you for the, for the list of branches that off button of branches that this user is allowed to. So in this case I was adding the CV and I user as a collaborator on the features and develop branch of the build. We've also added it's HTTP push. So you can now, you can now push, you know, via HTTP and you don't have to go via SSH, which is handy in some networking environments. So that's two ways that it works, depending on how Pager is configured if it uses local authentication so if the user accounts and groups are managed within Pager. So to be clear, this is not the case on Pager.io and that is not the case on this git. But if you use that the local authentication, then you know Pager knows about your password so you can provide user name and password and push. The open ID or the open ID connect authentications currently Pager.io and this git are using the open ID and we should be migrating them to IDC at one point. Then we don't know your password and we have no way to verify your password. So what you do is you're going to have to create an API token with the commit ACL. And then when you git push over HTTP, it's going to ask you for your username, which, you know, and the API token. So instead of the password is going, it's going to say password as you can see in the screenshot here, but you'll have to provide the API token and that will work. This has been currently enabled on staging Pager and I need to make the changes to enable this on Pager.io prediction as well as this git. But we have it, it's matter of configuring and we're starting Apache basically. We've added the possibility of customizing the new issue page. So when you have what you see on the right here is creating a new issue on the federal infrastructure ticket tracker. And you know it says you're about to upon a ticket to the federal infrastructure team. If this is the first time you're doing this, you can find more information at this URL here. And that text is exactly the same one that is placed under a template folder file name contributing that MD everything lowercase. And the text that I've put there, which you can see on the left side here actually shows on the on the new page on the new issue page. So if you want, if you want to inform your contributor of what's going to happen. Once they have opened a new, a new issue page, you know what's the workflow for issues are then going to be flag tagged assigned processed. If the tickets are automatically closed after two weeks of inactivity this kind of things. Well, these are things you can now put forward when the people are opening the these tickets. Another feature is the new issues in the static in the stats page of a project in the issue tab on the left here. You can see these graphs. So we have two graphs that we have we remade regenerated the old one looked didn't look as nice for one. And there was actually some issues with the data itself I think they were not working as good as I planned them in the beginning. So this is a V2, which so far seems to be working quite well. The first tickets is just a bar and for every week over the last year, so it goes 50 52 weeks or so. It tells you the number of tickets that have been opened that week and the number of tickets that have been closed that week. And in blue is the number of tickets opened and in red, the number of tickets closed. And as you can see, there are a few weeks where we actually did close more tickets than were open. So these are the good weeks and there are a few weeks where we got more tickets than we closed. So those are the bad weeks. And the bottom graph is the same idea except that it's it's the number of tickets that were open in that week. So if you look at this, this is again for the last year, 52 weeks. And we can see that we started the in August 2019, we had about 140 tickets. It's raised a little bit 150 and then it went down quite a quite nicely until May. And then we had a little bit of a peak and that's basically the beginning of the data center move. And then it's slowing slowly going down again. So that gives you an idea about what's your backlog size and how it evolves is it's growing up if it's going down if you're managing. If you're managing to keep up with it. So this is the federal infrastructure tracker. If you look at the same page for the pager project, you'll see enough work trends on the number of tickets opened over the last year. Just because we have more people asking for things than than we're able to keep up with. So that's interesting. We've also added a few new API endpoints. I don't think this list is exhaustive, but these are the ones which I wanted to put forward here. We've added one for commits information. We have added one that lists the files in the git repo and we've added the possibility of deleting a project via the API where the possibility of creating so far. This is adding the possibility of deleting. So the commit info is this is an example of a commit. You can see the author's name. We don't display the other email. You saw you have the commit date. And the number of seconds since the first of January, 1970, that's time stamp. It's unique with the time. Recognize what is the time offset based on that's the number of second. That's directly what I get to give us. Okay. And for the commit. So these are information which I get you extracts from. The UTC minus hours in in seconds. That's what that looks like. That's probably, yeah, that should be it. It's going to be the, so it's going to be the commit time. And the question is, is it coming time in local time or in UTC? And then the time zone, it's probably going to be coming time in local time. And then the offsets records the difference between the local time and the UTC time. So yeah, fun. And then we have the, the committer because commits can be authored by someone and pushed by someone else. In which, in which case the author and the committer differ in this case. There was a progress that I merged and therefore I did not push the commit and they did. Then you have the commit ash itself. You have the message of the commit and finally you have the parents. So the parents is actually a list because much commits will have multiple parents. This is a fast forward. And then you have the ash of the tree itself, you know, if you ever need it. Second example of an outcome is the, the number of files in it. So you can now browse the git repository to figure out if they are files or folders just using the API. You can see the content URL here is basically so the first item is the along big folder. The name is at the number of the folder. The pass is it's at the top level of the, the project. So the pass is just a limb big. If you, if I had a full folder under a limb big or version folders after a limb big, it would have a limb big slash versions. It says it's a folder and not a file. And then you have the content URL. So if you use the content URL, then and create that one, then you will get one of a lower in the, in the get repo and go into what's the content of that limb big folder itself. So you can now browse the content of the get repo just via the API and without having to do an actual git clone or anything. We've also done a number of changes to, to figure itself. We've ported the test suite to run with pie tests, which is pretty nice because we were running knows until now and knows is no longer supported. We are serving static files with white noise. I have no idea if I'm pronouncing that one correctly to be honest. And it's, it's pretty nice because it means the Apache, the, the, the web server. So Apache or G unicorn is not the one serving the, the assets, which actually makes deploying Pager on open shifts a lot more, a lot easier. We've also added the, the possibility of specifying the default branch of the git repository upon creation. So we've had the opportunity of specifying the default branch for a long, long time in Pager. Pretty much as far as I can remember, basically it's in the settings and then you have the default branch and you can set well, you know, master develop whichever you want. But, you know, you had to create a project, push something and then go to the, to the UI and specify that. Now you can directly do that at the creation. There is one, one thing to be aware of though is that if you create a git project on Pager, set the default branch, for example, to develop and get clone the, the git repository unless you've asked for the, the read me to be created. So if you didn't ask for the read me to be created the git repository, the git repository is going to be empty. And by default, get is going to make to place you in the master branch. So at that point you'll have to do a git checkout minus be develop, add your files there, git push develop, and everybody else who is going to clone your git repo is going to end up directly in the develop branch then. But the first, the first operations on on the empty repo that you just clone will be on the master branch even if the, even if on Pager you've said that default branch to be something. So note that there was a thing that may like one thing that for this particular feature, at least that I'm tracking and I don't know whether this will make this particular feature better is that get is making this configurable. I don't know if it's possible for us right now to make it so that we can make a default branch set in an empty repo by setting the property in the bare repo that we create. So if it's something that we can do that might actually enhance this feature at my reading of the feature in git itself is that this is not yet the case but it could be so we will probably eventually be able to fix that particular quirk, which would be nice. So a few of the changes that we've made here actually has made Pager a lot easier to deploy on containers in an open shift. For example, the fact that you can do HTTP push now means that you no longer have to deal with SSH and access of SSH to the git repository and managing this. So that's one less container to take care of and that's one less piece of security that you need to look after. This is also nice because it makes the configuration configuring Pager to work on container a lot easier. Again, you don't have to deal with Apache you can just use Unicorn and Pager will take care of this entire section of the configuration for you. And I have checked it actually so one of the things we were doing to force reload of statics files upon releases was that we would append the version number at the end of the static file. So you know if you go from Pager 5.10 to 5.11 the URL changes and therefore your browser reloads the file. We've white wise we don't need this anymore so we'll just be able to remove that little trickery and white nice is smart enough to figure out if the file has changed or not. And we'll let you read or note it or use your cache version for that. So so now let's move from from the upstream to to the this git. Well, we've forwarded the last year we've added integration with release monitoring. So I need to integration. You can just specify if you want, you know, no monitoring monitoring or monitoring and scratch builds and I need to encourage that information from the API and BFs accordingly. We have added bugzilla of rights. So what you see on the right on the right hand side is the screenshot of the the information you see bugzilla sign for Federa and April. You see two different people here. If you click on the edit then you see the screenshot on the left side and you can reset to default and that will be the main admin of the project or you can set it to someone else. Just there is just one thing there is that if you are the EPL field will show regardless of the of the project. Branches or support in bugzilla for EPL. That is, yeah, that's just something to be aware of. If your packages don't have EPL field, if it has, then you can set it to whatever you want. Something else that we've had it and that was something that just landed this morning because we love deploying things just before a conference. I guess visual conference makes that a little bit less risky though. Single click or fan. So when you are fan approach when you give the project to someone in this case if on this get you were to give the project to the offer user. You would still have access to the project. It normally doesn't remove you from the project to just change the main admin. And it doesn't change your watch status. So if you're if you're watching the project, then after that after you give and potentially remove yourself, you will still be set as watching the project, which makes you see seed on bugzilla tickets and so on. Your fun, your fun button here will do everything in one go for you. And that is a feature from Michal. So if you see him on IRC if you feel free to give him cookies, I'm sure you'll like it. It basically will give to the project to your fun user. Action would do but you would also remove you from the from the package so you won't have the access anymore, and it will reset the watch status of the project. So if you use that button, which I highly encourage you basically get everything done for you in one go in. Also sends a federal notification on the bus that this project was offered. And we've a dedicated offer topic. And the opposite is true or so we've added the single click adopt. So every so often, actually, you know, you have a single button and it will make you the main admin project will send a notification about it as well. The only thing is that you will see you will when you load the page you'll see a button is disabled. It will appear and not and that's because it's going to check if the package is retired or not. So if the package is retired, you won't be able to earn a fund it without going through a process. If the package is off but not retired, you'll just click that one button and the package will be yours. So those are the some of the things we've worked on this year. We do have a few more ideas and roadmaps and I let Nils comment too. So with the with the road our current existing roadmap that we're looking at right now this is like within the next few months or so depending on how things work out. We are going to be retiring a whole bunch of functionality we don't use anymore. And that's get a light and we're going to switch to the pager off back end will probably use pager authorized keys for the default because that doesn't require people to figure out how to configure SSHD, which is no fun. But we did document all that so yay, that should be very straightforward for people to send. So that route repo spanner support repo spanner is unfortunately kind of dead. And it doesn't quite work, even when it wasn't dead. So we're just going to rip it out and that'll simplify things considerably. If somebody wants to revive this particular functionality of being able to do clustered or ha get storage. I mean, yeah, we can look at it again. I mean it's just going to be removed and get we can always revive it later. Python to support that is the only thing blocking this at this point is that we've got to upgrade pager.io, because it's the only server left of the pager instances that are actually out in the wild. That runs on on Python to everybody else is Python three. Fed message support. Obviously, I think this has been beaten to death enough last year, we switch from using Fed message to Fedora messaging based on mqp. We're the only active instance of Fed message today, and ours is more abundant is the nicest way to put it. And so that's going to that that'll be a nice bit of cleanup. Oh, right. And I forgot about sent us also using Python to yeah we need to, we'll, we'll, we'll get both of these guys both sent us to get to us and to us.org and pager.io up to the to using the el eight builds running on Python three and then we'll be good to go there. But a couple of things that are kind of exciting that I think a lot of people will like is just little quality of life improvements is that moving to support Kerberos as an authentication mechanism for everything. So we already do this for coach a coach uses Kerberos and Fed package can already orchestrate Kerberos authentication tickets being passed through different services. So, adding support for this into pager will make it so that people don't have to deal with different ways to authenticate across the services to complete the basic workflow so you do can it once. Then you'll be able to commit, you'll be able to push, you'll be able to build all of it. And this is pushed through HTTPS so at that point we will no longer require that you need SSH access to do anything. So, yeah. So question in here cross repo code indexing you want to find usages of a macro. So I've been looking into this particular idea. I am unsure of how to do this, mostly because I think every avenue leads to us deploying elastic search somewhere, which I don't know how I feel about that. It could work. If anyone's got any ideas of like how to do this implementation. Keep in mind, pager itself is written in Python, we would really like to like integrate it nicely with all the other stuff that we have. Please come and talk to us about it, because like that would really be very helpful I think for a lot of use cases. And to the best of my knowledge there is no open source solution out there right now that does this sort of full global indexing to let you search and do stuff like that. So that is definitely something that I would, I would be interested in it somebody wants to file an issue and ask for it. I can't, Pingo, I can't answer this question so what is the future of source at fedora project org. I think you probably want to wait for the CPE talk that's going to happen later on in in nest. I don't know where that's going to be answered. But I would say that right now I would say that it's, it's probably going to stay in pager based because there's a ton of integrations and support and custom functionality that is built around our message bus around the API that we have for as well as a lot of other things so like if it's, if the, yeah, so that for now, just assume it's staying as it is and don't worry about it. We'll figure it out later. But yeah so like that's, that's what we've got right now for the initial roadmap ideas. And so reasons for orphaning is something that's coming up next I believe Mikhail has already got some initial work done for this, and it'll just need to be plumbed through for a future for the future release automatically notifying the devil list on the new orphan this is more message bus fun stuff. But yeah, we this is these are all things that. Yeah, yeah, the Julian mentions in the, in the chat that the re adding the reason for orphaning is actually already a pull request that we are reviewing and that will, and once we've merged that and kind of release for that that'll actually become available to everybody. New orphan, that's going to probably land on 512 and the notifications we just need to figure out if we put this as part of the of the girl if we use a set party, seeing like toddlers to do that. The little the toddlers thing yeah, it might make sense to do it in the toddlers thing since it would. But because then that way it will be asynchronous and scale. Yeah. So and to before we open up to more questions, some statistics about the projects. So this is basically every year, the number of commits the number of contributors and the number of tickets open and closed and progress open and closed for the year. So you can see that definitely 2019 and 2020 are lower are much slower from the development side and they than we used to be the number of commits as was divided by three in 29 in 2019 and divided by two again in 2020. There are a few reasons for that. I am no longer working on Pegger, primarily. So there is that there are the number of contributors has decreased a little bit although hold on in the chat here is definitely one of the most active one at this day. And nearly still always good at doing in the people relation or the public creation side of the other project and doing a good job at this. But it's interesting to look at the number of tickets closed. So 2019 was not a good year. So we only closed it 36% of the ticket opens of the amount of ticket open. 2019 2020 is actually looking much nicer. We are closing about 60% of the number of ticket that happens. But you can see that the number of requests, the number of requests closed is actually we always basically every contribution that is made to Pegger is closed. We do have a few products that are still open to this day, but most of them are actually integrated and reviewed and integrated as they are. So, yeah, we have more tickets. We have more tickets opening than we have than we're about to close, but the contributions that are made normally makes it into the code base. And that's quite nice to see the number of contributors is also interesting to see definitely dropped over the last few years. But it's also 2019 2020 looks to be in the same range of 2019, which is also nice. Yeah, there is a, we can see there is a dent. We can see there is a lower turnaround of code than than we have seen years before. We are so reaching project maturity to some extent. I know some people still have problems with the UI with some of they are still bugs for sure. But in the number of features we are so we are so not doing too bad for for what we need for what we need from Pegger. So that could explain that as well. Well, I want to say just a small bit about the stats. One thing to do when you when you look at this data what as Pierre said that there's this maturity and level here that that's starting to show up. Oh, Pierre dropped off. That's probably bad. So, as Pierre said that there's this maturity level in here. But also what it indicates is that there is from the primary users of of Pegger today, which are Fedora and Sentos. They have essentially reached the feature levels that they expect that they want for the workflows. And so there is there has been at least in my analysis, having started doing a lot of the ticket triage this year. A lot less requests for new stuff and just and and just a more mentioning of just more bugs or quirks kind of things to deal with. I mean, we've had feature requests and we've integrated those as we mentioned earlier. We've got Kanban boards now and we've got an API for traversing a Git repo without having to clone it. Those were feature requests from teams and people who needed it. And we've got collaborators, which is a disk it specific, which is a feature that a lot of disk it people wanted. So now we have those. But in general, I think we've we've started to reach a point where people are generally satisfied with the feature set that they have. And, and this is a big part of what I've been doing now is getting new people to start looking at at Packer as a solution. And this is where things have started to get kind of exciting, because we now have one of our first non fedora instances out in the wild. And that is from the mini picks project where they've now got a nice instance running based on Packer 510 zero as of right now. And it is the they were very happy about this at the solution. And they're actually the first instance I'm aware of that also doesn't even run on Fedora sent us. It runs on open SUSE. So this is actually an open SUSE based instance running on essentially the latest version of Packer. And they're they're very happy with it so far. Like I've been talking to them about it and they're very pleased with it. They love the API and there's some work going on right now to write some simple tools in C for being able to interface with Packer from the terminal. You know there's some in Haskell there's some in Python there's some in there's actually some in Pearl I found a little while ago. But you know these guys are very C oriented and the project that they're working on is essentially implementing a POSIX environment for a POSIX environment for windows on top of Windows NT directly. And so for them like C is the language that they're comfortable with and they're building tools based on that. Leonardo is asking why no rust I mean if you want to write a rust one it's it's not hard. If you can work with a rest API that returns responses in JSON. You can write a client and do anything you want. Oh right and there's the free software foundation considering using Packer as a hosting platform that is still ongoing. The global pandemic thing has sort of slowed everything down a lot, but I'm actively talking to them and working with them on on this sort of thing. So, yeah, the free software foundation is actively interested in this and I've been working with them on on that we've actually handled some bugs and feature requests for them as part of this so it's generally been I think where the growth curve has been very slow and steady, but people are starting to take interest and take note in it. There's a few other projects that are also interested in deploying it. And mainly because it's very flexible it's very customizable and it's very small. And it being written in Python makes it super extensible, which is something that a lot of people have told me is something that they don't have from other solutions out there. And so I think we've got something really good here and it's very it's it's been, it's been increasing in its in its slow binding of success slow bit of success so yeah, any other questions from anybody from either Pierre or myself. Oh yes and Jen Peterson, want to shout out for your for Haskell binding to Packer that you wrote for F branch which is super cool. So, any other questions and stuff. And anyone interested in rolling out Packer on their own instances somewhere. Oh, can we have a dashboard view showing packages that are about to be retired and merge trains up here. You want to, you want to answer these particular questions, like merge train sounds interesting dashboard thing is potentially simpler. So I thought in the order in which they appear in the chat here. The dashboard is something which we could do we have the information in the database so it's basically about creating it and displaying it. So that shouldn't be hard to do. We'll need to figure out how to do out to but it shouldn't be hard to do the merge train ID I think we already have it in the it has a different name. And so last the possibility and support spager and that's the possibility of running your test. Merging. You can create a progress dependencies in Zool. So you can say well project in progress one in project a needs to be merged for request one in project to to for a question in project C to be merged and Zool is going to see with the request to a project B merge with the progress a one of project a merged and if the test are passing on every single request and if the test are passing on the last one with the previous one merged, then it will merge for request one for request for request three in one atomic operation. They're not called merge train but they're already there and we are used and that is the I think one of the biggest CI system out there because that's what the open stack project you billion nutrients or quadrillions of tons or project I should say they're not even Python suddenly project out there that they contribute and mentor and maintain for some of them. Yeah, no that's I think the that might make this concept a little easier for people to rock might be maybe we need some way to add reporting to Packers interface about this sort of thing happening. I don't know exactly how we would do that but this might dovetail into some of the enhancements into how PR flags work that we've been talking about for a little while. So, for background here we're looking at enhancing the way that CI systems can interface with with Packer to give a richer information base for people for people to look at pull requests. And so there might be some opportunities there to enhance this to to make this a more coherent view for people to understand that things like the merge train concept are actually already happening. But we'll see the main difference with the merge training is that they are not part of figure itself, which to some extent I would consider as a feature more than a problem. Yeah, yeah so like something to keep in mind when we're talking about CI stuff for Packer CI is not built into the system you were intended to plug a CI system into it. The disadvantage of this is it makes it a little bit more difficult to have CI set up for your projects. The positive for this is that if your CI needs to be weird, it is a lot easier to handle that. If you have to do very complicated or specialized things, it is much easier to plug into Packer than it is to other systems that have integrated CI, because they have a model of how CI is supposed to work, and don't provide you the flexibility to make those things. So yeah, it's, there's pluses and minuses I think for what Fedora does and what, you know, distros do, which is heavily integration based. This model works out a lot better because we can be a lot more flexible, and we can actually model the way that we do stuff a lot more effectively. So hopefully that answers that more completely for people. Well, thank, I mean, it's not just, you know, like everyone's saying great project and stuff in the chat, I want to say it's not just because of us, it's because of all of you guys. All of y'all, you know, you can, you use it, you contribute to it, even with even filing issues or making pull requests, or even helping with the documentation and things like that, just all of that stuff makes this so much better. It wouldn't be anywhere close to as good as we are if it weren't for all of y'all. And so that is, that is what makes this so successful and so great. So thank you all for that. And if you, and if you didn't know you now know why nearly is the public relation person for figure. So if there, if there needs some love for that, please file an issues. We don't lose it because like this chat is not permanent persistent. So if there's issues with the thing is that the sorry what Pierre. The question for my dwell in the chat here is that the documentation for the bagger McDonald's needs some love. And I don't need to note that we only the default markdown documentation. So we didn't do which I think we link to. So only the watch documentation, the very basic. And then what is specific to so and mentioning linking these kinds of things. The rest is supposed to be, you know, go and find it in the string documentation about markdown than having yet another place where we document mark. It was a little bit of the idea, but it could be that doesn't mean that it doesn't need some love. And I'm more than happy to to look into that if I put it to your progress, which is even nicer. Yeah, sure. And the good thing about the parking documentation is that you get to mark down in the rest. She's very nice and very restructured text is way nicer than almost all the other formats that we have to deal with. I like that. But yeah, I think that's it for everyone is there any there's nothing else I think we'll just wrap up. Yeah, everyone for joining. Yeah, thank y'all.