Hi, On Wed, 20 Aug 2025 at 23:43, Ludovic Courtès <l...@gnu.org> wrote:
> 3. Infrastructure: Our infra has been unreliable for months, remaining > afloat thanks to a handful of people. We need more folks on board, > and probably more documentation/guidance to make that happen. > > See > > <https://guix.gnu.org/manual/devel/en/html_node/Contributing-to-Guix_0027s-Infrastructure.html>. 1. For example, since I’m back from vacation, I get “504 Gateway Time-out” from: http://ci.guix.gnu.org/ And I’ve no idea how I could help. (Aside avoid to fallback in French mode and loudly complaint about the time-out. :-)) Well, I remember years back when discussion with Mathieu about Cuirass. Somehow, it reads “The PostgreSQL database must be created beforehand.” and I’ve never taken the time to create it on foreign distro. And if I remember correctly, I reported something similar to Chris about the Build Coordinator when looking for potential Outreachy students. Arf, I’ve not checked all the current status neither their documentation but I think it would help if a potential contributor would have pre-configured environments for running CI tools (Cuirass, Build Coordinator, etc.). This works guix shell --expose=… -Df guix.scm ./bootstrap && ./configure && make and that’s great! However, it missing the counterpart for running: ./pre-inst-env cuirass register 2. To be honest, the repository ’maintenance’ is hard to navigate. Each I had something to do it here, it was much more easier (and probably faster!) to ask that someone does for me instead of doing myself. Somehow, one needs to know various untold and unwritten background, technical debt or history in order to contribute. I mean, it’s usually not super fun and mostly boring so any reason to escape the initial motivation should be smoothed. 3. Well, we already had the discussion several times and I don’t know it’s worth to raise it again. However, we have to admit that our scarce human resource are scattered across various non-orthogonal subsystems. Motivation isn’t fungible, for sure! That’s said, we are somehow victim about the kind of half-baked syndrome. :-) It reminds me Samuel Thibault’s talk in FOSDEM [1]: Many many existing bits, just needs polishing • The tail of “90% support done in 10% time, 10% support done in 90% time” • But would be so cool to have really working! Please, do not take me wrong. I know all the hard work behind what we have; I also know the amount of dedicated time and all the sacrificed hours. I only can be graceful for all that. Thank you for the years of commitment! We already discussed several times about the various non-orthogonal subsystems (Cuirass, Build Coordinator, QA, Data Service, etc.). And it’s a difficult topic. For instance, it reminds me a DebConf25 talk [2] – which reads to me xkcd #927 [3] – well, many tools help in creating a Debian package and the talk was about yet-another one with valid motivations… because there is too many complicated tools. :-) Look, our infrastructure relies on all these non-orthogonal subsystems (repository), from my understanding: artwork bffe build-cordinator build-farm cuirass data-service gcd-frontend guix-packages-website maintenance nar-harder qa-frontpage without mentioning mumi. I know, each of them has one reason to exist and I’m not questioning that. It just exposes how high the motivation needs to be in order to contribute to the Guix Infrastucture. :-) This #3 point does not help about the next coming months. However, we need to set some space for discussing a kind of project weakly-ruled ROADMAP about the Infrastructure. IMHO, one first actionable step could be to identify the bus factors: (1) Who? or (2) What? Then non-Whos people need to slowly spread the workload by adding some notes from discussions (meeting?) with Who about What. Somehow. :-) Cheers, simon 1: https://archive.fosdem.org/2019/schedule/event/roadmap_for_the_hurd/ 2: https://debconf25.debconf.org/talks/138-optimizing-the-debian-packaging-workflow-for-easier-collaboration-and-fewer-burnouts/ 3: https://xkcd.com/927/
