In reply to @sternenseemann:systemli.org
It's not just code complexity it's also semantic complexity you have to kinda be aware of when contributing

In reply to @sternenseemann:systemli.org
like the channel will be unable to advance until we have rebuild enough of the haskell packages set to build cachix

In reply to @sternenseemann:systemli.org
if it takes a day to rebuild we can just do it on the branch and have the cache fully populated already when we merge

In reply to @sternenseemann:systemli.org
and cachix is part of the nixpkgs:unstable job

In reply to @maralorn:maralorn.de
What we actually need is ofBorg or some other tooling to tell us if the new derivations resulting from a merge are already cached in hydra. That should be totally doable by pulling the nar files.

In reply to @sternenseemann:systemli.org
I don't see why we shouldn't merge master into haskell-updates prior to a merge: It causes the same outcome as if we merged the branch into master, but we migitate the risks by doing the rebuilds without slowing the channel down and we even can catch unlikely regressions before the ruin someone's day

Well my argument against it are 1. it will slow us down which is might be annoying for our process and for the person doing the merge who wants to get it done and 2. this could actually mean more unnecessary rebuilds. Imagine we have a change to a core package like random which leads to mass rebuilds and a small change to master which leads to us postponing the merge and then another change hits master leading to rebuild all packages again with the old "random" and then we need to rebuilt everything with the new random before we can merge. (I kinda dread the loop of merging in master, rebuilding, merging in master, rebuilding and never getting to actually merge. That’s theoretically possible.)

But those are only arguments why it isn‘t completely free to merge in master. When our merges causes a lot of rebuilds, yes, then we need to obey the same rules as the rest of nixpkgs and build them before merging into master.

And now that I think about it: Merging in master, retriggering an eval, seeing how many builds will be rebuild and merging when it’s less then 100 or something seems to be a matter of 10 minutes and is probably totally sane.