Hi Ludo, On Fri, 24 Jul 2026 at 10:27, Ludovic Courtès <[email protected]> wrote:
>> When it’s a two-lines update and leaf – ’guix build -P1’ is doable and >> indeed carefully done! – waiting for the bot appears to me “wasteful“. >> Because once the bot reports green, someone™ still needs to rebase on >> the top of current master and… check again! :-) > > Most of the time, nothing will need to be rebuilt after 3 days. Not necessary rebuilt but check again. Somehow, for “trivial“ (meaning two-lines update and leaf – ’guix build -P1’ is doable and indeed carefully done by committer), I think the now (even the right now) of committer agenda is better than some other unknown time slot scheduled by bot, i.e., maybe never because committer has moved on. Anyway. :-) IMHO, the point is to align committer agenda with bot schedule. > But also: the bot gives a track record that the PR was indeed tested at > one point in time. It makes mistakes less likely, which pacifies > relations among ourselves and removes pressure from committers. I agree. That’s why I think we should be stricter about merging to master and more relax about pushing to team branches. Another story, I guess. >> …I agree we should not adapt the Policy because the state of our CI; to >> the contrary, we should have the Policy that appears to us the right one >> and invest to make the CI “good enough”. > > Yes, I agree. For one example about an improvement: https://codeberg.org/guix/guix/pulls/9999 The bot says: Results of evaluation [2961](https://pulls.ci.guix.gnu.org/eval/2961) for commit [`db7c8ef3ee`](/guix/guix/commit/db7c8ef3ee24940dbdeecbf0f3ae8272757b0a13): * Successfully built 457 packages: […] * Failed to build 116 packages: […] And the parent of db7c8ef3ee is a3ae7cb106, thus: $ guix time-machine -q --commit=a3ae7cb106 -- refresh -l nghttp3 | cut -f1 -d':' Building the following 328 packages would ensure 567 dependent packages are rebuilt Hum, 457+116 = 573 which isn’t 567. Who is correct? Who is able to more is able to less too… indeed. :-) For another example: https://codeberg.org/guix/guix/pulls/10021 There is a pile of comments for the same evaluation and sent by batch at the same time. Another story, I guess. Aside this annoyance, the PR had been open 6 days ago and CI completed 7 hours ago. In the meantime, team-audio has received other contributions, great! If a committer goes to this team-audio PR webpage: https://codeberg.org/guix/guix/pulls?labels=423042 then it’s hard to know which PRs are worth for merging when considering Policy and CI outcome. Well, there is the “approval” indicator but it might also be applied by another team member that just reviewed and approved the PR. Therefore, it could be nice to have a dedicated green label applied by the bot when one evaluation had been successful – for instance “ci-built” with green* color. When sending the comment, the bot also adds the “ci-built” green label. This way, it becomes easier for the committers to filter the PRs (almost) ready because compliant with CI and it realigns committer agenda and bot schedule. ;-) Please note: It does not matter if then another evaluation reports a failure against the most recent master. Because if one evaluation passed at one moment, then it means the PR is ready to engage and crossing the final line is very close. At worse, if after a success, the bot reports then a failure that is harder to fix and requires changes, bah the committer just remove the “ci-built” label by hand, meaning this PR isn’t ready to engage yet. I mean, this minor feature of “ci-built” green label does not need to be a perfect mirror of CI status. Let avoid to over-engineer. ;-) Instead, it’s a booster for the committers and it helps them to navigate the PRS and to apply the Policy considering CI outcome. WDYT? Cheers, simon *green color: the same green as “wishlist” or as “user-reviewed”, your preference! :-)
