Ludovic Courtès <l...@gnu.org> writes: > 1. Continuous integration for pull requests. It will improve > legibility (for contributors and reviewers), increase reliability > (for users: fewer breakages), and reduce frustration for everyone. > > See <https://codeberg.org/guix/maintenance/pulls/18> and Cuirass’ > Forgejo support (new release Real Soon Now).
One observation from the current patch testing setup, one big issue when this was first being used was that when big changes (e.g. branches/core-updates/staging) hit the master branch, the bordeaux build farm substitute availability dropped, and this was an extra delay to resuming testing patches. Add on to this that the current system for queuing up branches to be merged is based around Debbugs/Mumi, and thus has a lifespan of 4ish months now before it'll stop working, so I think it's important to consider what can be done about this, and I'd maybe view it as a prerequisite for testing Pull Requests, assuming those builds happen on the bordeaux build farm. It isn't obvious to me what the best approach is though, maybe ordering branches to be merged could be handled through Pull Requests, or maybe we could put in place a generated branch system, where the changes in Pull Requests can be grouped together through a Milestone and ordered via the Pull Request Dependencies, which I think could have some key advantages. A comprehensive plan for the minimal viable approach is needed though.
signature.asc
Description: PGP signature
