Hey Chris,
> That sounds sensible. On the specific name, given this is just about > substitutes, and at least in my opinion has nothing to do with > continuous integration, maybe picking just another word would avoid > thinking too much, it could be bordeaux, or hippo, or anything > really. As you say, stability and not being tied to a particular machine > is the important thing. The substitutes coverage is one indicator to take into account but there are many others. For instance, the evaluation speed, the failed evaluation count, the average evaluation builds completion time, the availability of the connected build machines between other things. Deploying a solution that builds substitutes is fine, but as soon as it is deployed and accessible to all Guix users, the system administrators will have to monitor it and maintain it in the long run. Having two heterogeneous build infrastructures on two sets of machines, providing different metrics will make the update and maintenance of those machines harder. I hear your point about K-out-of-N policy and it also makes sense to me. However, we should maybe consider doing it using two similar infrastructures. Thanks, Mathieu