In reply to @maralorn:maralorn.de
From all I can tell peti never gave a frack about rebuilds. Just merge it.^^

In reply to @maralorn:maralorn.de
The problem is that this would be a moderately invasive operation on cabal2nix/hackage2nix and none of us maintainers has a lot of free time or familarity with the code base. So any outside help on this topic would be appreciated.

In reply to @sternenseemann:systemli.org
also this is yet another layer of complexity added to the process we have currently which we already made quite a bit more involved than before (in terms of moving / interacting parts, not necessarily usability)

In reply to @sternenseemann:systemli.org
which has the same outcome really, but avoids blocking the channel by accident (I believe cachix is a channel constituent)

In reply to @maralorn:maralorn.de
If cachix builds on our branch and not on master then in 99% of cases that means that cachix is already broken on master. So in a sense that's not our fault. It should be fixed as soon as possible but that's orthogonal to our PR. Besides build fails channel advancement depends on all package build being finished so that does not have a lot to do with cachix.

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.