One change the Janitor can try to make automatically is upgrading debhelper version. Newer debhelper versions include support for compiling code with additional security measures. So we end up with more secure packages.
If ~everyone migrates off an older debhelper version, then the debhelper developers don't need to keep maintaining that code and can delete it, leading to a more maintainable code base, less complex documentation that says "X, unless you're on an older version, when it's Y" and so on.
The Janitor is pretty good at trying something like upgrading debhelper, then doing a build, and running the package tests, performing a package diff to make sure nothing unexpected happened then proposing a merge. Doing this by hand is slow and laborious. If debhelper always tried to autoupgrade to the newest version when it was run, it would be frustratingly slow.
And once the merge proposal is accepted, then it's clear which packages need human attention, and which were able to be cleanly migrated by automation. We use this a lot in the janitor. Run a fixer over all eligible packages, and see which ones succeed. Then investigate a handful of packages that failed, see if there is a common pattern that can be extracted and fixed. Then we reapply the fixer to all the remaining packages, see how many were fixed, and repeat the process until there are only a very few remaining.
One change the Janitor can try to make automatically is upgrading debhelper version. Newer debhelper versions include support for compiling code with additional security measures. So we end up with more secure packages.
If ~everyone migrates off an older debhelper version, then the debhelper developers don't need to keep maintaining that code and can delete it, leading to a more maintainable code base, less complex documentation that says "X, unless you're on an older version, when it's Y" and so on.
The Janitor is pretty good at trying something like upgrading debhelper, then doing a build, and running the package tests, performing a package diff to make sure nothing unexpected happened then proposing a merge. Doing this by hand is slow and laborious. If debhelper always tried to autoupgrade to the newest version when it was run, it would be frustratingly slow.
And once the merge proposal is accepted, then it's clear which packages need human attention, and which were able to be cleanly migrated by automation. We use this a lot in the janitor. Run a fixer over all eligible packages, and see which ones succeed. Then investigate a handful of packages that failed, see if there is a common pattern that can be extracted and fixed. Then we reapply the fixer to all the remaining packages, see how many were fixed, and repeat the process until there are only a very few remaining.