So, it might be good to have a discussion about "continuous integration", what this means, and how it applies to Guix.
I believe the term comes from the field of software development, as a practice, it has multiple components, but I think the most significant one comes from the name. When practising continuous integration with software, you should continuously integrate your changes (patches), normally this means you promptly merge all the different changes together in your version control system. This practice is utilised for a large proportion of changes to Guix, they are merged to the master branch. However, the way the staging and core-updates branches are used is an example of not following "continuous integration". Changes can wait for a while before being merged in to the master branch. It seems to me that continuous integration is a related concept, but separate to the building things (packages/system tests/...). When thinking about continuous integration, it might be good to think about what the ideal workflow would be for Guix changes, assuming for a moment that the "building things" situation was perfect. Currently, changes are held in core-updates and staging so that substitutes can be built, but if you can build substitutes as fast as you want, I think there would still be advantages for batching the changes. Imagine if the changes that would go in to core-updates go in to master, even if there are substitutes are available, it could result in Guix users having to download large amounts of substitutes, and depending on the change, some proportion of these changes may be redundant as the change to the derivation wouldn't have altered the behaviour of the software. Therefore, for changes that affect a large number of derivations without much functional impact on most of those affected derivations, it would reduce the impact to batch those changes somewhat. Anyway, there are some thoughts, Chris
signature.asc
Description: PGP signature
