Repository
https://github.com/fedora-infra/fedora-packages
Reducing Technical Debt
What is the project about?
Fedora Packages is a web app that lists software included in different Fedora repositories. It can be used to lookup what version of software will be shipped with the next Fedora release or to find a package source to upgrade the package (this thing will be important further).
For example, there is a great productivity tool called ranger that can be installed easily with dnf install ranger.
Because it is included in Fedora package repository, there is no need to compile it from source. But as you can see from command line that version is a little outdated and doesn't include all the latest greatness.
There would be no problem to use outdated version if it didn't contain a nasty bug with broken search which requires package update.
The ranger page on Fedora packages lists the available version of ranger, which is 1.7.2 for current released Fedora (fc28) and 1.7.2 for future Fedora release (always named Rawhide, or upcoming fc29).
That means nobody submitted work to bring ranger to a new version in future release.
What needs to be fixed?
To update a package to a new version, you need to find package source that only contains instructions for packaging and helper files. That's the way how package source is different from application source. The link to ranger package source is supposed to be in Sources tab of ranger page, but clicking the tab produces nothing and following Sources link directly produces error 404.
That is the thing that needs to be fixed - the Sources tab in Fedora Packages.
What was the solution?
I went to GitHub and filled a bug some weeks ago:
which was closed as a duplicate. I could not see that anybody was fixing that, and I decided to fix that myself, because it is open source. The first step was to get the project running on my machine, and - the system didn't run.
I ran into technical debt.
Technical Debt
Technical debt is some technology that new people can not pickup, and former developers don't have time to play with anymore. The way to deal with it is to either make the technology more attractive, or to port it to more modern stack. I decided to try the latter. Fedora Packages contains a lot of references to some fedoracommunity package, and its deployment scripts are located elsewhere, so my time was spent into researching how fedoracommunity is related to fedora-packages, then I updated documentation and removed things that are 100% not used anymore.
Work done
Except for minor README fixes submitted by other people, I've submitted few PRs while learning codebase details.
- https://github.com/fedora-infra/fedora-packages/pull/377
- https://github.com/fedora-infra/fedora-packages/pull/378
- https://github.com/fedora-infra/fedora-packages/pull/380
- https://github.com/fedora-infra/fedora-packages/pull/382
- https://github.com/fedora-infra/fedora-packages/pull/385
The broken thing that was missing is that fedora-packages requires more files to be downloaded during the build process. One of these files was Xapian Database with indexed packages, and the URL for that gone 404.
We've been able to restore the missing database thanks to cooperation of https://github.com/cverna who retained repository rights after previous maintainer left the project. He merged all PRs and helped to switch the primary branch from develop to master and now the workflow is more smooth for future git merges and rebases for other contributors. Now everybody can run fedora-packages locally and start contributing fixes without additional hassle.
git clone git@github.com:fedora-infra/fedora-packages.git
cd fedora-packages/devel
docker-compose up
Run the code above and follow http://127.0.0.1/packages and if it doesn't work - fill an issue to get in touch.
Roadmap
The goal is still to bring technical debt to minimum to allow new people making contributions faster. There is an idea for Standard layout for Python web applications which is still work in process, and the core of it is that project layout should be machine-readable so machines can help people. Then one day my personal bot could checkout a project, safely run it in container, and it if works - give me the editor window to fix just the bug I need with all that handy live reloading and backround test runners already in place.
The plan for near future.
- Decouple Python application from Apache
- Map
staticresources independently of Apache config
- Map
- Fix missing images in
docker-composesetup (need to fetch them)- Move dependencies out of Docker and Vagrant scripts into single script
- Factor out
staticcache refresh into separate app (Flask maybe)
- Document current deployment process with Ansible
- Fix the bug with the Sources tab
- Deal with the rest of
fedora-packagesissues