On 2026-07-14, Ludovic Courtès wrote: > Andreas Enge <[email protected]> skribis: >> Am Mon, Jul 13, 2026 at 11:32:00PM +0200 schrieb Jelle Licht: >>> Ludovic Courtès <[email protected]> writes: >>> > Also, I would like us committers to always wait for @guix-cuirass-bot >>> > feedback, except in cases where the pull request targets a branch other >>> > than ‘master’ that pulls.ci won’t be able to build. >>> I worry that this will slow (almost) trivial PRs down a lot, but that is >>> obviously me wearing my "let's get some code merged" hat on ;-). >> >> Same here. I sometimes build packages from pull requests and their >> dependents (maybe sometimes only the direct ones?) and merge them, which >> is essentially the same as "running a bot by hand". For instance, >> ungoogled-chromium. Waiting for the build bot does not add anything then. > > What waiting for the bot brings is a public track record, and the simple > fact that it avoids mistakes that any person could make
For many builds, the bot is definitely helpful... :) I will admit I mostly treat the bot as a bonus data point rather than a requirement for merging... I was submitting pull requests for diffoscope, but was eventually encouraged to stop submitting trivial updates... The CI bot often produces a wave of results in rapid succession and it is not immediately clear which results are from which iteration of the PR ... I mean, it lists the commit but it is not immediately clear that the commit built is the current PR or some older iteration without doing a bit of git archeaology... when it takes effort and time to evaluate what the bot is evaluating kind of limits the value. :) I often see updates several days after a PR was already merged, which is confusing. > (and it runs ‘guix pull’, which committers are unlikely to do > manually). I almost always test 'guix pull' before pushing ... but does the bot test 'guix pull' rebased against master, or just whatever commit the PR was based on? I find the latter to be of only limited value... For the linux-libre team (f.k.a kernel-team) it is really unclear which of the builds were already failing (and there are usually quite a few, which is a problem unto itself). I usually push to the kernel-updates branch anyways (which also produces substitutes as well as testing the builds). Obviously not all teams have such a branch that gets built by CI out of the box... I also build locally for aarch64-linux (and sometimes for x86_64-linux) before merging. There are also usually security-relevent updates in the linux-libre kernel, sometimes two or three in a week, for, let me check... nine (9!) different generations of kernels) and waiting an arbitrary and unpredictible amount of time till the bot builds seems less than ideal... So I guess I have some concerns about how this would affect linux-libre kernel updates. I guess I should file more issues about the bot, but they usually come up right in the middle of some huge process that I just want to finish without going down yet another rabbit hole (and not even sure or confident where to start looking into the issues to actually propose fixes)... live well, vagrant
signature.asc
Description: PGP signature
