 Federa Packager Dashboard is a service that's designed to help all Federa packages. My name is Sanjik Zatloka. I'm from Federa QE and those two other people that you can see on the title slide work on the project too. Lukash Roberts wrote the front end part. I wrote back end and Josef Skardanka was leading the project and giving feedback and reviewing the code and the changes. So the origin of Packager Dashboard, it all started by an email email of Mero Hronchok in 2019 on Federa Mailing List and he sent this idea out into the world and three of us came out with an idea that we can work on such a project. This is an original mockup what Mero sent out how the dashboard could look and if somebody of you uses Federa Packager Dashboard nowadays or as we'll be able to see or you all will be able to see in the demo it looks very similar to what the original mock image looked like. What are the goals of Federa Packager Dashboard? The main goal is to collect data from all relevant sources, bugzilla, body, cache and nowadays even some more like a retrace server which stores data from ABRT reports. The main core idea behind Packager Dashboard is to present all the information about all your packages in Federa that are relevant to package maintenance. It has to be presented in a fast and responsive way that means we have to cache most of the data or all the data because as somebody of you who use redhead bugzilla might know that it isn't always that fast especially if you are maintaining a package with lots of bugs and trying to filter some of them out and some other core ideas are to make packages life easier so to save time to Federa Package maintainers bit, maintainers from community or maintainers from redhead and even lower the barrier of entry into packaging world a little bit at least. Here are some results of some feedback that was posted by Packager Dashboard users to mailing list thread about Dashboard and now it's time for demo. So this is the title screen after our Packager Dashboard. You can start by typing your username or start by clicking on help button which I'll probably show later because this is a whole page that should be used if you are Dashboard. We can try to open Dashboard of Mira Hunchuk. So this is Packager Dashboard. Everything you can see here are potential action items or potential issues or active updates against your package. So everything that somehow affects any of your packages is shown here. Yeah, we can start with, yeah, what was there. In the top part of Dashboard you can see Federa release schedule which can be useful if you can't manage to keep track of Federa release or next Federa release so you can see how we are getting currently to Federa 35. Think under eight minutes that is something we have added pretty recently. Those are package calendars and you will be able to see calendars that are relevant to packages that you maintain. So as we can see here Mira is maintaining core Python interpreter in Federa so he might want to be able to see release schedule of Python itself. And also this is something that I would like to appeal to anybody listening that we are looking for help with these package calendars. I'll send out an email probably today or tomorrow on how you can contribute and how you can add another package calendar because currently we only support Python and Grown Release Schedules. And I imagine lots of other packages might find it useful. And so since we have lots of things down here I'll start with showing filtering options so you can filter out something directly so you can write an exact match of package. You can use regular expressions and you can you can use Boolean logic there so I can write not Python. So yeah as you can see I'm pretty good out of there. You can write there as many as many filters as you want. And apart from that there are easier ways to filter out results so you can click on these buttons. So right now I'm showing only box and you have some tags near the box. You can filter by those tags in advanced options but I won't be showing everything here. Right now in this demo you can try that yourself on anybody's package reward. The other interesting thing is updates and we have recently added a build list into each update so you can take a look and see what builds are part of any update and these links lead to Koji build page if that loads up here. And those are overrides and another interesting thing that we are showing on package reach board are pull requests and what might be useful are the results of a CI for specific pull request so we can see that it's failed and something succeeded or for this pull request everything succeeded so we can keep track of changes that somebody else is sending against their packages. These are fails from Koji. We are showing fails from federal health check that service run by Fabio Valentini so thanks for that. I'll show orphans on the orphan page because Miro obviously cares about these packages and I don't have many of them depending on something orphaned and this is another thing that we have added recently. These are data from retrace server and as you can see we are showing two kinds of information. The first one is if your package has any ABRT problems reported against itself so we can see something is reported and let me, I should learn keyboard shortcuts in Chrome and the other thing is that we are doing some statistical algorithms on top of all the data and explicitly showing problems if they are outlying in some way so here we can see there is one problem that has count lot higher than the others we are showing explicitly and you can link, you can click on the link to see all the problems and in the settings menu you can disable some of the elements of package dashboard if you for example don't care about calendars or federally scheduled you can turn that off you can disable some of federal releases so if you don't care about anything from raw height you can disable that and you can instantly see that counter box changed a lot you can filter bugs by priority by tags or you can hide entire sections of some sort of data so right now I'm showing data from retrace server and then the final thing you can filter on is that you can hide packages that you own through group by default package report will show you all the packages that are owned by you and by groups that you are part of you can you can see there is free state switcher and the middle option will show only packages that you own directly and that those packages might be part of Lua packages sick and the other option would hide all the packages owned by the group so even if you own them directly they won't be shown at all and the final part of the demo would be the orphan user just especially especially username you there is nobody in in fedora fedora account that's that has nickname orphan but we are showing all the all the orphan packages or packages that are depending on something that's orphaned which means a package can be directly orphaned which means it will go out of fedora if it's not taken by somebody else or you can have a package that depends even indirectly on something that's orphaned and for this situation package it has an interesting visual visualizing tool which can illustrate even indirect indirect orphans so as we can see Apache common file upload file upload depends on portlet and that depends on something that's orphaned so we can instantly see and decide if you want to take maintenance ship of something or you want to disable some support or some feature in your package so it doesn't depend on something that's going away from fedora i will take a look if there if you can see something more complicated not much yet but this may be more interesting now it's still never mind sometimes there are pretty interesting situation where something depends on lots of different orphan packages and you can see a nice graphs on package dashboard but now it's not not the case so that would be everything for demo and let's go on with talk so some implementation details of mainly the back end or our chrome because i'm not working on front end and i don't understand front front ends at all and if you would have some questions about front end you will have to reach uh lukash brabez who's mentioned on the first slide so for oraclem it's heavily based around flask and celery it's written in python and it's heavily using robust parallelization through celery because we are refreshing cash for ton of packages and that wouldn't work without a huge number of workers that can fetch information parallel manner front end is a javascript application and it's written in react so just to mention that oracleman package dashboard is currently deployed in fedora's open shift instance thanks fedora infrastructure team for helping with that i wouldn't have been able to make that work just myself and and one of the our goals or long-term goals is to make oraclem some sort of common common source of truth for fedora related information so we are aiming to build an easy to use easy to understand api where you can ask any information that's related to fedora for for example what are current fedora releases and i want it in api friendly way you can query oraclem nowadays or what are versions of package a what versions of package a are in all the fedora releases this is something that pagir is currently using today if you are using this git and if you can imagine the version table of some package the data are pulled from oraclem yeah we have some i'll get more to that on on a roadmap slide but we still haven't finished some documentation for the api so it's still in progress what was accomplished during during defconf not during since defconf as i've said some of those things already in in demo retrace server integration was was added into oraclem and showing of data from retrace server and we have finished and enabled authentication and showing of private bugs you can even look at somebody else dashboard if you are if you are a package error you can see all the private bugs for any fedora package so we can try that if you don't own any package with private bugs and we have added contextual package specific calendars and we have finished back-end part for customized dashboards this is something that will still take some time before it's finished especially front-end side but you will be able to build your own dashboards from based on any number of users and their packages or some packages explicitly and share that that dashboard with your colleagues your team or other community members working on some some sort of stack in fedora we are we are really looking forward to that because it will it will make possible some more use case for fedora package dashboard and what are other plans are other plans amping up integration with fedora ci and showing some some more more results and in some more user experience UX friendly way exploring integration with other fedora processes and services and investigating some possibilities for downstream usage of fedora package dashboard many more optimizations because sometimes the dashboard can take a bit too low especially if you are a new user on dashboard and if you have lots of packages the dashboard won't won't be exactly fast fast on first load this is caused by the fact that we are caching only data for people who visit it at least for at least once in 14 days so if you don't visit it visit it that often the first load will be slow and we have we have some ideas and some changes refactoring of the code to make that faster we are planning to make use of fedora messaging make make less listener for fedora messages so we won't have to keep calling for all the all the different federal services especially bugzilla for example which is pretty slow but we will be able to just keep listening and receiving messages about bug changes and faster things that this is something that I mentioned and yeah documentation especially api documentation and integration testing so these are the most important links you will find fedora package dashboard on the first link if you have some feature requirements feature requests bug reports or if you want to work on some part of the dashboard we'll be glad for any any ideas help and even some pull requests you can visit visit repositories on bug gear back end is oracle and front end is package report feel free to report an inbox to to the front end which is the last link we will move that to the correct project if if it's for example back end issue you don't have to to care about this too much thanks for your attention and now it's time for your questions do you see yes trigger this yes you will see your package as it if it depends on something that's orphaned you will see it on your dashboard and you will see which which package that your package is depending on this orphaned and when it's going away from fedora and you'll be able to decide and act upon upon that i'm i'm really thankful for mirror hunchback's data data parsing scripts because he generates the json source for us and we are just parsing that and displaying on package dashboard so if we don't have any other questions i would like to thank you a lot for for listening for your attention i'm really sorry about the video issues and i hope you have enjoyed the talk anyway so enjoy a few last talks on this year's federal nest and you are welcome everybody it's a pleasure to work on dashboard