I recently added my first package. It supports auto updating via passthru.updateScript. I can see the new version was detected on 24th.
However, the package hovers around 11k place in the update queue. In fact, with time it drops further back.
Questions:
It is fine to setup a Github Action in the original package repo to open PR in nixpkgs with the version and hash bump?
More strategically, what’s holding up r-ryantm from processing more package and clearing up the queue? Is it accessinble infra, Github throttling, some human effort?
Whether or not it’s allowed I’m not sure, but one notable disadvantage of doing this is that it would mean that version bumps require a committer’s approval, whereas automated update PRs opened by r-ryantm (via the passthru.updateScript) can be approved and merged by a package’s maintainer alone.
Indeed, I realised this reading related thread. I would stronly prefer nixpkgs-native automation, I just don’t know if there is any hope in that package to be picked up relatively soon. I would like to put as little strain on people as possible, so we can have this amazing giant repo of packages.
It’s infra (or the lack of some clever way to use less compute to achieve the same goal). Last time I checked, we had the infra to give every package an automated version bump about once a month or so, and the goal of the supervisor queue is to try to distribute that fairly so that frequently updated packages don’t hog resources from less frequently updated ones. (It’s a flavor of priority queue; don’t expect it to be FIFO.) Maintainers of packages who can’t allow them to be a month out of date (browsers, e.g.) run their own updates.