This week, the Fedora Packager Dashboard left the testing period and is available for wide use. Why should you care about it? And what is it about?
Fedora Packager Dashboard is a web application designed to make the lives of Fedora Packagers easier. It aggregates and shows all the relevant data for package maintainers on one page, structured, searchable and filterable. You’ll see things like current bug reports, updates, issues regarding all your packages at one place, without needing to spend time reading your emails and/or monitoring dozens of different services one by one. Caring about your packages will be easier and less time-consuming with Fedora Packager Dashboard.
What is on the Dashboard?
You’ll get information about your packages from: Bugzilla, Bodhi, Pagure, Koschei, repochecker and orphans. Has somebody opened a bug report against your package in Fedora or EPEL? You’ll see that on your dashboard in a blink of an eye. Did somebody file a PR against your package? It’ll appear on your dashboard! Do you depend on something that was orphaned? You don’t need to check your email for list of orphaned packages, you’ll see that right on your dashboard with dependency graph and paths to the orphaned packages (even if it is behind multiple layers of dependencies)!
What can you do on your dashboard?
Fedora Packager Dashboard provides you with numerous possibilities of filtering displayed data. Do you maintain many packages and care more about some of them? You can filter out packages you don’t want to display!
You can use simple filtering (like !python to hide all python packages from the dashboard) or even full blown regular expressions to customize the view as you prefer.
Apart from this, there are also some predefined configuration options, mostly to filter bug reports. Does somebody else maintain EPEL branches of your packages? You can go ahead, disable EPEL in settings panel and see only Fedora items on your Dashboard. Do you only care about CVEs? You can filter out the rest of bugs and see just them!
You can easily select a single category of information that you want to see. Are you about to fix some bugs? Go ahead, click on the “bug” icon in the top right corner and pick the one you want to work on.
Feature set of Fedora Packager Dashboard is expanding rapidly. The best way to learn about everything you can see and do on your dashboard, is to visit our help page (by clicking on the “question mark” icon on your dashboard).
In the end, I’d like to mention that it is possible to view a dashboard of any Fedora contributor. We’re currently only showing data that are publicly accessible, so you don’t need your FAS password. You can also view Dashboards for packager groups, or the orphaned packages together with packages depending on them by viewing the dashboard of the ‘orphan’ user.
What to expect in the future?
By releasing the Fedora Packager Dashboard as a production and supported service, our work doesn’t end. We have long term plans for it. On top of our list currently sits the possibility to show private bugs (after FAS authentication on your dashboard) and contextual schedules and calendars for packages you might be interested in (e.g. Do you maintain some Python packages? You might want to have a Python Release Calendar on your dashboard.)
We’d like to ask you for any feedback you have on the Dashboard, be it issues you might see or ideas for new features. You can do that by commenting on this article, or even better by letting us know on our issue tracker.
We’d also like to invite you to help us with developing the Packager Dashboard, or Oraculum (the backend handling data processing and caching). Our code is open and we welcome fixes and updates from the community.
It’s a great service and I use it regularly. Thanks for maintaining it!
If anybody is is interested in the repochecker service (which provides the broken dependencies data), it is maintained and developed by me, and it’s a nice little self contained, unprivileged web service written in Rust, behind an nginx reverse proxy.
Contributions are very welcome, especially for making the data more usable (e.g. more specific queries?) or fixing bugs / better filtering of false positives, and for making it easier deployable (it might live on something like communishift in the future, but for now, it runs on a server I host myself).
The code lives on pagure and should be relatively straightforward to hack on: Overview - ironthree/repochecker - Pagure.io
For new users, maybe it is better to add “Start your first package… or adopt a new one”? Instead of just stating that one is not a packager.