To start off, if this has been proposed before or already exists please pardon my ignorance.
So, after looking at void-updates.txt it seems to me that we can improve the speed at which some SIMPLE packages update in our repo by making them update automatically, so here is the what/why/how I am proposing:
A script that checks void-updates.txt once a week, and attempts to update the packages just by updating the version number and checksum and then running xbps-src on it. If xbps-src is successful, the script would then either email the maintainer, submit an issue on the github page, directly submit a PR for the updated package or some combination of the three. This would be done for all packages in void-updates.txt, excluding duplicates of the same package (ie it will only try to update packageXYZQ.n to packageXYZQ.n+newest; not to n+1, then n+2… all the way to n+newest).
Many packages ca be updated by simply incrementing the version number in the current template file and re-calculating the checksum. Yet they do not get updated because of various reasons with that package’s maintainer (busy, sick, no longer involved, etc).
A dedicated computer with some python and/or shell scripts and xbps-src. The script should only target simple packages that just need a version bump.
Some Thought on implementation and potential pitfalls.
- Packages with patches should not be attempted as they are not simple, and the goal of this script is to reduce mindless work and auto-update simple packages.
- Packages that have a daily release should be restricted to being run through the script once or twice a month.
- Many packages will build on some architectures and fail on others. So we should build for a problematic arch that has a high failure rate, once again to ensure the script only auto-updates simple packages.
- Even if the script succeeds and submits a PR, it should email the normal maintainer.
- The script should keep a history of failed builds (package and exact version).
- For builds that fail, the output of xbps-src should be available, and emailed to the maintainer.
- Packages that fail to build due to missing or out of date dependencies should be logged into to history and not re-tried until thoes dependencies are met.
- Packages that fail to build for issues unrelated to dependencies should be logged (package and exact version) and avoid running them again for at least a week. Packages that fail twice should be delayed a whole month before being tried again, and packages that fail 3 times (package and exact version) should be blacklisted from the script. Failing because of a build configuration problem or something similar is not a sign of a simple package.
Thus I propose we work on writing a script that does these things to help out Void.
What do you guys think? I think it would be worthwhile to have something like this helping out the maintainers (if they don’t already have something like it).