| 26 May 2021 |
 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.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 |
