| 26 May 2021 |
 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.org
Domen Kožar: on a related note we should probably add you to the maintainer list for your haskell packages Yes, 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
Domen Kožar: on a related note we should probably add you to the maintainer list for your haskell packages * 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.org
the channel will advance when all constituents of a certain aggregate job are built not when all of nixpkgs is built Are 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.al
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 being a maintainer should be very much an opt in | 13:49:36 |
| joe (he/him) | In reply to @sternenseemann:systemli.org
being a maintainer should be very much an opt in Of course :) This PR would be gated on that person's consent | 13:50:01 |
| joe (he/him) | perhaps there just aren't that many people in that position | 13:50:23 |
| maralorn | In reply to @joe:monoid.al
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 I wouldn‘t be a huge fan of this. I want a lot of packages to have maintainers, but we only want packages to have maintainers which people honestly care about. Otherwise we will quickly get bogged down by unnecessary work. | 13:50:58 |
| joe (he/him) | understood :) | 13:51:41 |
| sterni (he/him) | In reply to @maralorn:maralorn.de
Are 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? yes, that's why you often have to compile stuff when using nixos-unstable-small because not all jobs necessary for nixos-unstable proper have finished building | 13:52:15 |
| maralorn | But I am talking about nixos-unstable. Are you talking about nixos-unstable-small? | 13:53:03 |
| sterni (he/him) | yeah, but every channel has its own aggregate job set that determines when it advances | 13:53:44 |
| sterni (he/him) | so they work the same essentiall | 13:53:51 |
| sterni (he/him) | * so they work the same essentially | 13:53:55 |
| sterni (he/him) | nixpkgs/trunk/unstable -> nixpkgs-unstable
nixos/unstable-small/tested -> nixos-unstable-small
nixos/trunk-combined/tested -> nixos-unstable | 13:54:31 |
| maralorn | sterni (he/him): My point is: all of haskellPackages is part of the aggregate jobset that needs to be finished for unstable to advance. | 13:54:32 |
| sterni (he/him) | no? | 13:55:37 |
| sterni (he/him) | hypothetically as long as cachix is built, nixpkgs-unstable could advance without all of haskellPackages being built | 13:56:17 |
| sterni (he/him) | but with the inclusion of cachix in nixpkgs-unstable for example we effectively need to have build a significant portion of haskellPackages | 13:56:46 |
| sterni (he/him) | so I guess in a sense what you are saying is true | 13:56:55 |
| maralorn | https://nixos.wiki/wiki/Nix_channels
For a channel update to succeed, two conditions need to be satisfied:
- Particular jobset evaluation needs to be completely built ie. no more queued jobs, even if some jobs may fail
- Particular jobset evaluation's tested/unstable job needs to be built succesfully
The jobset for nixos-unstable is nixos:trunk-combined which includes haskellPackages.
The tested job for nixos:trunk-combined does not include haskellPackages. But that matters only for successful builds.
| 13:57:17 |
| maralorn | In reply to @sternenseemann:systemli.org
hypothetically as long as cachix is built, nixpkgs-unstable could advance without all of haskellPackages being built No | 13:57:33 |
| sterni (he/him) | hmm, okay then you are right | 13:57:57 |
| sterni (he/him) | nice that the wiki documents this I skimmed through a perl script in nix-channel-scripts earlier, but most have overlooked that check | 13:58:25 |
| maralorn | Sorry for being so insistent on this. But I think having that fact straight is helpful.^^ | 13:59:10 |
| sterni (he/him) | but what are you trying to argue for? this means that nixpkgs-unstable blocks on all of haskellPackages being rebuilt, so this makes my argument even stronger | 13:59:19 |
| sterni (he/him) | remember, rebuilds that would involve rebuilding all of haskellPackages don't happen on master, they go via staging | 13:59:37 |
| maralorn | I am not arguing for anything. I agree with your conclusion. I just wanted that we agree on the facts. | 13:59:54 |
