Hi Steve,
Steve George <[email protected]> writes: > Hi, > > One of our current challenges is that we don't want to commit changes to the > master branch that cause large rebuilds. As I understand it the main issue is > that the build farm takes a while to build all the dependent packages and in > the meantime uses that do guix pull won't have substitutes so will have to > build locally. > > Nix seems to solve this by having developers push to a different branch from > the one that users pull from [0]. This seems like a good solution, has Guix > tried this previously, am I missing something? > > A rough proposal for how this would work: > > 1. Developers push to a new branch (e.g. 'main') Note that there has been a GCD to move master to this branch. So I think using this branch is not really wise in case we want to move to it in the future. Of course it's just a detail. > 2. CI builds each commit > 3a. If the build is successful the commit is updated on master > 3b. The substitute from the build is available to users I think this approach has some issues. While on one hand, it makes substitutes better available for the users, I think there are at least two notable disadvantages: 1) Incentives Since the branch is no longer facing users, developers get more incentivized to push commits that might break something. They know that if they mess up, the process will get back to them and they might fix it easily, without much effect on the users. And the more commits like that there are, the more time it takes for us to get a commit that's buildable. While we might tell ourselves that we do not want to do that, I think even subconsciously this is going to have some effects. Nixpkgs suffers especially in times before a new stable channel release when the channels might not get build for multiple days. This slows down the updates that might sometimes be necessary, which gets me to the second point. 2) Security updates The Nixpkgs model does not take into account any other way than first commiting to master and then letting CI push it to unstable branch. So even with critical security updates that should land ASAP, you can see delay. On the unstable branch, it might regularly be up to a week, sometimes even two. On the stable branches it's usually less. What's worse, if we wanted to move closer to their model, bigger rebuilds (500+ packages iirc) get to a staging channel and this is then merged to master ~twice a month. I've seen that even for a security update their hands were sort of tied and they had to go through this branch to deliver the fix to the users. And this can take up to ~3 weeks if merge just appeared. So I am not completely convinced this is the way to go. Wouldn't it be enough to give users the tools to find out what commit already contains substitutes for the packages they're interested in? Cuirass/data service already sort of give out this information through the API, so it's just a matter of proper filtering of the informations. Rutherther
