| 10 Apr 2023 |
 K900 | Or at least where I notice people complaining | 13:40:43 |
 tea | btw, kind of unrelated, but saving for later: why doesn't ofborg do nixpkgs-review-pr anymore? | 13:41:18 |
 cole-h | I'm still somewhat hesitant (how many times has this happened in the past and caused an issue? honest question), but I wouldn't block anything in that case. Though "at least 500, or at least 1000" is kinda noodly. | 13:41:24 |
| K900 | It doesn't happen that often | 13:41:45 |
| K900 | But I'd say that's an argument for it, not against | 13:41:58 |
| K900 | As most PRs will never see it | 13:42:06 |
| K900 | Also, the exact number can always be tweaked later if it becomes a problem | 13:42:56 |
| cole-h | In reply to @noob_tea:matrix.org
btw, kind of unrelated, but saving for later: why doesn't ofborg do nixpkgs-review-pr anymore? I'm not sure it ever did...? AFAIK, it only ever built packages based on the commit message in a given PR. | 13:43:02 |
| cole-h | Which is why nixpkgs policy is to name commits attr: description | 13:43:35 |
 7c6f434c | Never did | 13:43:52 |
| 7c6f434c | From time to time there are people who run nixpkgs-review-pr on many PRs | 13:44:17 |
| cole-h | ofborg does check if all changed packages still evaluate, but not build. | 13:44:59 |
 hexa | In reply to @cole-h:matrix.org
Try now? works | 13:46:35 |
| hexa | thanks | 13:46:40 |
| 7c6f434c | I would say that 5000 packages from many of the lighter ecosystems are still lighter than a single Chromium rebuild. | 13:47:43 |
| K900 | For Hydra, absolutely not | 13:48:29 |
| K900 | Chromium gets thrown on a very wide machines | 13:48:38 |
| K900 | All the other packages get like two cores | 13:48:45 |
| K900 | And the coordinator overhead is unfortunately massive | 13:48:56 |
| 7c6f434c | Well, about wide machine, I wonder if I can find 5000 packages that are still lighter than Gimp, or where the cutoff for getting such a ton of cores lies | 13:50:32 |
| 7c6f434c | Although coordinator overhead can always be high enough to overshadow the builds, maybe | 13:51:08 |
| K900 | Chromium is 2 hours on a big-parallel machine: https://hydra.nixos.org/build/215069962#tabs-buildsteps | 13:51:45 |
| K900 | That's probably comparable to the time it would take Hydra to schedule 5000 no-ops | 13:52:37 |
| 7c6f434c | A few thousands Lisp packages were like an hour on my laptop, I think… | 13:52:44 |
| K900 | Which is admittedly not a good look for Hydra | 13:52:46 |
| K900 | But what can you do | 13:52:48 |
| K900 | In reply to@7c6f434c:nitro.chat
A few thousands Lisp packages were like an hour on my laptop, I think… Yes, this is specifically a Hydra problem to a certain extent | 13:53:15 |
| K900 | The cutoff number could be way higher if Hydra could scale better | 13:53:32 |
| K900 | As we have a lot more compute capacity hypothetically available than we actually use | 13:53:50 |
| 7c6f434c | Speaking of what we can do… this is specifically Hydra scheduler, right? So bundling lower-impact light-weight packages as dependencies of a single named Hydra job would help? | 13:58:02 |
