On August 5, 2025 3:11:28 PM EDT, Robin Candau <an...@archlinux.org> wrote:
>Hi everyone,
>
>We are very happy to announce the addition of a new member to the "buddy"
>family: bumpbuddy! [1]
We can always use a new buddy!
>Initially introduced to Arch staff during last year's Arch Summit as the
>"nvchecker-poc" [2], bumpbuddy is now (a)live and ready to assist our package
>maintainers and users in monitoring new upstream releases for our packages.
>
>## What is bumpbuddy?
>
>Bumpbuddy is a daemon watching for new upstream releases for our packages.
>
>It automatically opens GitLab issues for out of date packages [3], keep them
>updated if needed (e.g. if a newer upstream release supersedes the initially
>reported one) [4] and closes them once the matching version has been pushed
>[5].
>
>It intends to fill the gaps in current methods for new upstream release
>tracking and reporting by proposing a centralized and automated solution.
This is awesome. I have some packages that don't get updated often and don't
have enough users to get flagged quickly, so this will make it way easier to
get new versions into [extra] in a timely manner!
>## Benefits for package maintainers
>
>Bumpbuddy takes advantage of the `.nvchecker.toml` file from GitLab's packages
>repo to perform automated tracking of new upstream releases. Therefore,
>Package Maintainers won't need to rely on manual `pkgctl version check` runs
>or "homemade" solutions to track new upstream releases for their packages
>anymore.
>
>The reporting of new upstream releases being done via GitLab issues offers a
>(public) place to discuss and collaborate around eventual problems or blocking
>points preventing a new release from being packaged [6].
>
>Assignment to those "out of date" issues is opt-in and can be enabled by
>reacting with the "package" emoji from bugbuddy's user settings [7].
>Note that such issues are automatically opened as "confirmed", so
>bug-wranglers will not get assigned.
>
>## Benefits for users
>
>Thanks to bumpbuddy automated tracking and reporting, our package maintainers
>should now be aware of new upstream releases without requiring users to
>manually flag packages out of date via the dedicated button on Archweb (which
>we actually intend to get rid of at some point, more on that in the next
>chapter).
>
>Another benefit for users is that, as opposed to the current "flag out of
>date" feature, GitLab issues offer a public place to look for (or ask for) the
>state of a pending update. This should hopefully allow for more transparency
>towards users wondering why a specific update is taking some time to be
>packaged.
>
>## Current specifications and future work
>
>Bumpbuddy currently runs every 3 hours, which means that it may take up to 3
>hours for new releases to be reported and for the associated GitLab issue to
>be automatically close once the matching version has been pushed.
3 hours is a pretty wide interval so this isn't a significant issue but I
should mention anyway: only concern here is that some smaller upstream code
hosting sites may flag this scraping as malicious. Again, though, 3 hours is a
pretty wide interval and I doubt it'll cause any problems.
>It's also worth reminding that the version tracking is based on the
>`.nvchecker.toml` configuration file of packages repo, meaning that an
>erroneous configuration file may result in erroneous version reporting and
>that packages that miss a configuration file will not be monitored.
>
>Here are a few mid / long term goals we have for bumpbuddy:
>
>- Provide a web overview for reports [9].
>- Provide an API endpoint for `pkgctl version check` (to produce faster
>results).
>- Manage "out of date" status for packages on Archweb and get rid of the "flag
>out of date" button; which is manual (and therefore error prone), may be used
>wrongly/abusively (e.g. to report bugs or send some spam), is highly dependent
>on packages popularity and lacks transparency (as it doesn't provide a public
>place to discuss eventual blocking points).
>- Open merge requests rather than (or in addition of) GitLab issues, including
>the result of `pkgctl version upgrade` (regarding our future goal to adopt a
>gitops workflow for packaging).
>- And more... [10].
>
>## Conclusion
>
>This is the first iteration of bumpbuddy and things are still at a fairly
>early stage, so bear with us and don't hesitate to open issues [10] to submit
>bug reports or suggesting improvements.
>
>I would like to thank everyone who helped us improving bumpbuddy so far by
>opening issues, sharing opinions and opening merge requests.
>I would also like to give a special thank to Segaja, mh4ckt3mh4ckt1c4s and
>yan12125, who have been (beta) testing bumpbuddy for the past few months, as
>well as a huge thanks to klausenbusk & gromit for their amazing work and
>precious help on that project!
>
>[1] https://gitlab.archlinux.org/archlinux/bumpbuddy
>[2] https://pkgbuild.com/~antiz/presentations/Nvchecker_PoC/
>[3]
>https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issues/1
>[4]
>https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issues/1#note_291863
>[5]
>https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issues/1#note_291988
>[6]
>https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issues/1#note_291683
>[7] https://gitlab.archlinux.org/archlinux/bugbuddy/-/issues/1
>[8] https://archlinux.org/packages/extra/x86_64/timeshift/flag/
>[9] https://gitlab.archlinux.org/archlinux/bumpbuddy/-/issues/10
>[10] https://gitlab.archlinux.org/archlinux/bumpbuddy/-/issues/
>
Great work all! I'm looking forward to the arrival of bumpbuddy issues in my
package repos.
Best,
Campbell