Comment by Foxboron
2 years ago
It's all part of the same problem domain; How do we rearchitecture the release process of Arch so we can support multiple architectures.
The amount of people that understand this problem domain, have the time+energy to work on it and is actually able to see it too completion is.. well. Not many.
I tried to hack on buildbot, as I wrote in that email, but I have been questioning the maintainability of trying to fit what we need on top of buildbot. In constrast to writing something from scratch.
I wonder if something like that should be built on top of GitLab now that you have migrated to it. GitLab CI supports multiple runners for a single job, so the workflow might be that you merge a merge request which modifies PKGBUILD/.SRCINFO, the CI picks it up and based on labels/tags dispatches it to different runners running possibly on a completely different architecture for building. The runners then send the artifacts back and the job publishes them. The nice thing about this is that most of the parts are already there handled by GitLab itself, you just have to draw the rest of the owl.
This doesn't help at all as you need to coordinate so-name rebuilds across multiple architectures. This implies you need to some way to orchestrate a staging repository and have building do rebuilds towards this repo interactively until all issues are solved.
Retrofitting this ontop of gitlab sounds painfull. I don't even know if we would like to be that tied to a singular forge.