 | Haskell in Nixpkgs/NixOS | 719 Members |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | More Nix: #community:nixos.org | More Haskell: #haskell-space:matrix.org | 143 Servers |
| Sender | Message | Time |
|---|---|---|
| 26 May 2021 | ||
 maralorn | In reply to @sternenseemann:systemli.orgAre you telling me that haskellPackages is not part of the nixos unstable job? | 13:12:11 |
| maralorn | 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. | 13:12:43 |
 sterni (he/him) | nixos:trunk-combined:tested tests a bunch of VM tests which are much more elaborate, so unstable is usually behind nixpkgs-unstable | 13:13:08 |
| sterni (he/him) | it probably depends on haskell in some way as well | 13:13:14 |
| sterni (he/him) | haskellPackages is part of the jobsets, but not directly of the aggregate job cnotrolling channel advancements | 13:13:39 |
| sterni (he/him) | In reply to @maralorn:maralorn.deyou could just check the drv outpaths before and after test merging — if they differ we have no cache | 13:14:29 |
| maralorn | Yeah.true. | 13:14:56 |
| sterni (he/him) | 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 | 13:15:57 |
 Marty Rosenberg | has anyone tried to use miso on a modern macos? the pinned nixpkgs don't seem happy. | 13:16:20 |
| sterni (he/him) | maralorn: cdepillabout: there has been a staging-next merge since the last time we merged master including changes to LLVM for example, so there will be rebuilds | 13:17:08 |
| maralorn | In reply to @sternenseemann:systemli.org 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. | 13:25:50 |
 Domen Kožar | +1 for treating haskell-updates similar to staging-next, mass rebuilds so make sure there are big regressions and everything builds | 13:26:21 |
| Domen Kožar | it does add overhead, but it's no worse than finding out the same stuff in master | 13:27:25 |
| Domen Kožar | it's not so much overhead but rather delay | 13:28:45 |
| sterni (he/him) | I think not doing it risks a “merge and forget” practice were interactions between haskell-updates and master we couldn't have been aware us ruin other people's day on master and we may not even notice it | 13:29:13 |
| maralorn | Again, cases where merging master and haskell-updates will lead to a build fail that didn‘t exist on one off the branches before seem super unlikely to me. But yeah, I mean we have this job set exactly to not merge build errors into master and we have actually improved on our quality assurance their in the last weeks. | 13:29:51 |
| sterni (he/him) | either way we would need to fix it right away in order to get our new haskell-updates branch working again | 13:30:03 |
| maralorn | * Again, cases where merging master and haskell-updates will lead to a build fail that didn‘t exist on one of the branches before seem super unlikely to me. But yeah, I mean we have this job set exactly to not merge build errors into master and we have actually improved on our quality assurance their in the last weeks. | 13:30:08 |
| sterni (he/him) | the difference is largely for how long master would be affected by whatever trouble we'd run into | 13:30:21 |
| Domen Kožar | I'd just kindly ask to avoid what Peti did to Cachix, when the build broke, it was removed from channel blockers | 13:31:29 |
| Domen Kožar | if I have a heads up I can help out resolve issues with packages I maintain | 13:31:47 |
| sterni (he/him) | Domen Kožar: on a related note we should probably add you to the maintainer list for your haskell packages | 13:32:54 |
| sterni (he/him) | To sum my position up: We need to be sure that merging haskell-updates into master is safe, i. e. doesn't cause over 500 actual rebuilds and doesn't cause any build failures we are not aware of. The only way to be sure those things are not the case is having built the entire haskell-updates jobset on hydra with a reasonably freshly merged master | 13:34:33 |
| maralorn | In reply to @sternenseemann:systemli.orgYes, please! Avoiding future cachix disasters was one of the primary "user stories" while we were designing our new process with timely maintainer pings. | 13:44:34 |
| maralorn | In reply to @sternenseemann:systemli.org* Yes, please! Avoiding future cachix disasters was one of the primary "user stories" I had in mind while we were designing our new process with timely maintainer pings. | 13:44:59 |
 joe (he/him) | I wonder if it'd be possible to construct a mapping between Hackage users and GitHub handles, and make a PR adding those handles who've interacted with NixOS on github as maintainers for their Hackage packages | 13:48:46 |
| joe (he/him) | For some reason I was missing as a maintainer for my packages until recently | 13:49:00 |
| maralorn | In reply to @sternenseemann:systemli.orgAre you sure about this? I think the logic is this: "Advance nixos-unstable if (everything in nixos:trunk-combined:tested has finished succesfully && everything in nixos:trunk-combined has finished with any result)" Am I wrong about this? | 13:49:02 |
| sterni (he/him) | In reply to @joe:monoid.albeing a maintainer should be very much an opt in | 13:49:36 |
| joe (he/him) | In reply to @sternenseemann:systemli.orgOf course :) This PR would be gated on that person's consent | 13:50:01 |