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

Reply via email to