It’s been close to a year since I started contributing to KDE long term, and since then a lot has happened.

Spectacle is out as part of the Applications suite as of KDE Applications 15.12, and not only do the users like it, other devs love it too. Maintaining Spectacle isn’t as hectic as it used to be in the early days. I get a steady stream of mostly benign bug reports, which is nothing I can’t handle in a few hours over the weekend. Wayland support still hasn’t materialised though, and it looks like it’ll be a while. Proper High-DPI (retina displays) support did materialise though, courtesy of Kai Uwe Broulik, and will land in 15.12.1.

Something I’ve come to realise, however, is that day-by-day I’m gravitating over to the Sysadmin side.

The Project Predicament

KDE’s online infrastructure is gigantic, no small part of which is taken up by Git servers. I’m not sure of the exact numbers, but a ballpark figure for the number of repositories we host would be in the 2,000-2,500 region.

We’re also in the middle of a migration. KDE’s Project Management Website runs on ChilliProject. ChilliProject is slow and unwieldy, but that we could make do with. What we can’t make do with is that ChilliProject is deprecated and is no longer developed. There are bugs and security holes and we’ve had to disable chunks of functionality to mitigate these.

So we’re migrating to Phabricator. We already have a Phabricator instance running, and quite a few projects have already been migrated. So far our experience has been good, and the Phabricator documentation is pretty good. And pretty funny (seriously, you should see their website).

Let’s Git Overhaulin'

Back in September, we set up a read-only mirror of KDE’s public project repositories on GitHub. d_ed liaised with GitHub and got is the organization username, and then I got busy mucking around with the post-recieve hook in our git.kde.org repositories.

The scripting itself was pretty simple. bcooksley had already written a small python script that git push-ed only branches and tags to upstream servers, so it was just a matter of executing that with the GitHub remote URL.

Now KDE has its own infrastructure of read-only git mirrors which mirror every repository, not just the public project ones. They’re the Anongit servers, a network of (currently) 6 such servers spread worldwide which developers can clone from. They’re available at anongit.kde.org.

Since we already mirror code from git.kde.org, why couldn’t we just add the GitHub remote URL to the list of servers to mirror to? Because we don’t push to the Anongit servers, we tell them (via a HTTP hook) that git.kde.org has been updated, please pull changes.

Now there isn’t anything inherently wrong with this approach; it’s just that we have no control over what happens if one of the Anongit servers go down. We’d ideally want to log failed mirroring attempts, and to do that effectively we’d need to push to our mirrors and log failures (and maybe retry if a mirroring attempt failed).

Propagator

Sysadmins hold the keys to much of KDE’s infrastructure - user accounts, passwords, SSH keys, you name it, we have it. Understandably, we don’t just let anyone be a part of the Sysadmin team. But the truth is, KDE’s Sysadmin team is severely understaffed and the list of tickets to attend to is miles long. We need all the help we can get.

That said, you don’t need to be a part of the core Sysadmin team to be able to help them out. And Sysadmin work isn’t just SSH-ing into servers and running commands - there’s plenty of coding to be done, and that work doesn’t need access to the keys.

So, Propagator. Over the winter holidays, I got to work on a small-ish daemon that would manage our entire distributed git infrastructure - and alleviate the Sysadmins’ need to ever touch the Anongit servers themselves.

Propagator is written in Python 3, and uses a Celery task queue to mirror-push changes to our Anongit servers. We also wanted to converge code-paths for pushing to GitHub, so Propagator does that too. Propagator also creates, sets the descriptions on, moves and deletes repositories on the Anongit servers via a SSH API, and on GitHub via their REST API.

In fact, with Propagator, managing repositories is as easy as creating them inside Phabricator. Propagator will automatically create repositories on the upstream servers (both Anongit servers and GitHub) on first push if they don’t exist, effectively making things zero-administration.

What about moves, renames, and the rest? Well, you log in to a shell on git.kde.org and run:

$: mirrorctl create AwesomeRepo.git "Awesome app to do something super cool"
$: mirrorctl rename AwesomeRepo.git AwesomeApp.git
$: mirrorctl delete AwesomeApp.git

…and so on. Propagator will not send out requests to every single configured upstream server and tell it to carry out these commands. Easy as pie.

Unfortunately, Propagator now lives inside the repo-management repo in KDE, but I do plan to separating it out into its own repository and distributing it as a standalone product in its own right as a KDE project.

Closing Notes

KDE is awesome. No, it really is.

We see a lot of newcomers pop up on KDE’s IRC channels and mailing lists and ask how to contribute. For the record, we appreciate code, documentation, artwork, translations, evangelism and publicity (but do refrain from streaking across campus with a giant KDE tattoo… *wink wink*).

And we need Sysadmins. If you have a particular set of skills that make it a nightmare for people like us to have problems with our online infrastructure, we want you.