There are a lot of small changes that can be made to the Debian archive to increase the overall quality. Many of these changes are small and have just minor benefits if they are applied to just a single package. Lintian encourages maintainers to fix these problems by pointing out the common ones.
Most of these issues are often trivially fixable; they are in general an inefficient use of human time, and it takes a lot of effort to keep up with. This is something that can clearly be automated.
Several tools (e.g. onovy’s mass tool, and the lintian-brush tool that I’ve been working on) go a step further and (for a subset of the issues reported by lintian) fix the problems for you, where they can. Lintian-brush can currently fix most instances of close to 100 lintian tags.
Thanks to the Vcs-* fields set by many packages and the APIs provided by hosting platforms like Salsa, it is now possible to proactively attempt to fix these issues.
The Debian Janitor is a tool that will run lintian-brush across the entire archive, and propose fixes to lintian issues via pull request.
The aim of Debian Janitor is to take some drudge work away from Debian maintainers where possible, so they can spend their time on more important packaging work. Its purpose is to make automated changes quick and easy to apply, with minimal overhead for package maintainers. It is essentially a bit of infrastructure to run lintian-brush across all of the archive.
The actions of the bot are restricted to a limited set of problems for which obviously correct actions can be taken. It is not meant to automate all packaging, or even to cover automating all instances of the issues it knows about.
The bot is designed to be conservative and delight with consistently correct fixes instead of proposing possibly incorrect fixes and hoping for the best. Considerable effort has been made to avoid the janitor creating pull requests with incorrect changes, as these take valuable time away from maintainers, the package doesn’t actually improve (since the merge request is rejected) and it makes it likelier that future pull requests from the Debian Janitor bot are ignored or rejected.
In short: The janitor is meant to propose correct changes if it can, and back off otherwise.
The Janitor finds package sources in version control systems from the Vcs*- control field in Debian source packages. If the packaging branch is hosted on a hosting platform that the Janitor has a presence on, it will attempt to run lintian-brush on the packaging branch and (if there are any changes made) build the package and propose a merge. It is based on silver-platter and currently has support for:
The Janitor is driven from the lintian and vcswatch tables in UDD. It queries for packages that are affected by any of the lintian tags that lintian-brush has a fixer script for. This way it can limit the number of repositories it has to process.
There are a couple of things I am doing to make sure that the Debian Janitor delights rather than annoys.
High quality changes
Lintian-brush has end-to-end tests for its fixers.
In order to make sure that merge requests are useful and high-value, the bot will only propose changes from lintian-brush that:
- successfully build in a chroot and pass autopkgtest and piuparts;
- are not completely trivial - e.g. only stripping whitespace
Changes for a package will also be reviewed by a human before they make it into a pull request.
One open pull request per package
If the bot created a pull request previously, it will attempt to update the current request by adding new commits (and updating the pull request description). It will remove and fix the branch when the pull request conflicts because of new upstream changes.
In other words, it will only create a single pull request per package and will attempt to keep that pull request up to date.
I’m slowly adding interested maintainers to receiving pull requests, before opening it up to the entire archive. This should help catch any widespread issues early.
The bot will be upfront about its pull requests and try to avoid overwhelming maintainers with pull requests by:
- Clearly identifying any merge requests it creates as being made by a bot. This should allow maintainers to prioritize contributions from humans.
- Limiting the number of open proposals per maintainer. It starts by opening a single merge request and won’t open additional merge requests until the first proposal has a response
- Providing a way to opt out of future merge requests; just a reply on the merge request is sufficient.
Any comments on merge requests will also still be reviewed by a human.
Debian janitor is running, generating changes and already creating merge requests (albeit under close review). Some examples of merge requests it has created:
Using the janitor
The janitor can process any package that’s maintained in Git and has its Vcs-Git header set correctly (you can use vcswatch to check this).
If you’re interested in receiving pull requests early, leave a comment below. Eventually, the janitor should get to all packages, though it may take a while with the current number of source packages in the archive.
By default, salsa does not send notifications when a new merge request for one of the repositories you’re a maintainer for is created. Make sure you have notifications enabled in your Salsa profile, by ticking “New Merge Requests” for the packages you care about.
You can also see the number of open merge requests for a package repository on QA - it’s the ! followed by a number in the pull request column.
It is also possible to download the diff for a particular package (if it’s been generated) ahead of the janitor publishing it:
$ curl https://janitor.debian.net/api/lintian-fixes/pkg/PACKAGE/diff
E.g. for i3-wm, look at https://janitor.debian.net/api/lintian-fixes/pkg/i3-wm/diff.
The current set of supported hosting platforms covers the bulk of packages in Debian that is maintained in a VCS. The only other 100+ package platform that’s unsupported is dgit. If you have suggestions on how best to submit git changes to dgit repositories (BTS bugs with patches? or would that be too much overhead?), let me know.
The next platform that is currently missing is bitbucket, but there are only about 15 packages in unstable hosted there.
At the moment, lintian-brush can fix close to 100 lintian tags. It would be great to add fixers for more common issues.
If you have any concerns about these roll-out plans, have other ideas or questions, please let me know in the comments.