| 10 Oct 2023 |
 Alyssa Ross | in general changes that only touch maintainer-list.nix should be pretty rare | 10:23:02 |
| Alyssa Ross | generally if somebody is adding themself to the maintainer list, it should be in the same PR where they are added as the maintainer of a package | 10:23:22 |
| Alyssa Ross | (occasionally, as you've seen, it makes sense to separate it, if somebody new is adding two packages at once or something) | 10:23:37 |
| Alyssa Ross | but OfBorg is like, a couple of hours max | 10:23:43 |
 Lily Foster | In reply to @cafkafk:gitter.im
would it be possible to fast track changes that only touch maintainers/maintainer-list.nix? I've got no actual idea how ofborg works, but the checks on that probably aren't super expensive, could be nice if it could get those through faster. What sort of "fast track" are you thinking, like skipping eval checks? | 10:23:51 |
 cafkafk | more like scheduling them first... assuming eval checks don't take super long | 10:24:12 |
| cafkafk | In reply to @qyliss:fairydust.space
in general changes that only touch maintainer-list.nix should be pretty rare to add quantity to that, ~772 (https://github.com/NixOS/nixpkgs/pulls?q=maintainers+in%3Atitle) | 10:26:09 |
| cafkafk | which is admittedly peanuts | 10:26:15 |
| Lily Foster | In reply to @cafkafk:gitter.im
more like scheduling them first... assuming eval checks don't take super long The most expensive parts of the eval checks by far are outpath calculation (with meta checks), which wouldn't be any less here. I do actually intend to make that less expensive in general because it's getting pretty obscene at this point, but I'm admittedly a bit scared to dive into what horrors lie in all that | 10:26:29 |
| cafkafk | very understandable tbh >_> | 10:27:05 |
| Lily Foster | * The most expensive parts of the eval checks by far are outpath calculation (with or without meta checks), which wouldn't be any less here. I do actually intend to make that less expensive in general because it's getting pretty obscene at this point, but I'm admittedly a bit scared to dive into what horrors lie in all that | 10:27:44 |
| 11 Oct 2023 |
|  εΉΈη« (πππΎπ/πππΎπ) changed their display name from FC (they/them) to Fay (she/her). | 20:54:43 |
| 12 Oct 2023 |
 @adam:robins.wtf | why does ofborg queue nixos tests on darwin? nixosTests.lxd.container on aarch64-darwin | 14:53:43 |
| Lily Foster | In reply to @adam:robins.wtf
why does ofborg queue nixos tests on darwin? nixosTests.lxd.container on aarch64-darwin that probably could actually be optimized to not bother queueing builds on platforms that won't eval for darwin, but it would take some refactoring iirc and also it doesn't really cause much delay to do so and let eval fail on the builder and report it back (except when the aarch64-darwin builders get backed up and so checks stay pending for way too long....) | 14:59:48 |
| Lily Foster | but it's not a nixos test specific problem | 15:00:27 |
| Lily Foster | * that probably could actually be optimized to not bother queueing builds on platforms that won't eval, e.g. for darwin, but it would take some refactoring iirc and also it doesn't really cause much delay to do so and let eval fail on the builder and report it back (except when the aarch64-darwin builders get backed up and so checks stay pending for way too long....) | 15:00:47 |
| @adam:robins.wtf | Right :) | 15:04:55 |
| @adam:robins.wtf | I guess I just figure no need to spend any cycles doing an eval that will never succeed | 15:06:04 |
| @adam:robins.wtf | especially given that, as you point out, the aarch64-darwin builders get backed up | 15:06:20 |
| Lily Foster | oh i agree no need to, just also saying it's a bit due to how ofborg handles that right now | 15:06:37 |
| Lily Foster | it's on my "nice to have" list of those i'm vaguely putting together | 15:06:56 |
| Lily Foster | (i really gotta pretty up some lists and plans and get community feedback going for ofborg soon...) | 15:07:53 |
| @adam:robins.wtf | Yeah it'd be nice to see where you think the priorities are :) | 15:13:25 |
| Lily Foster | it'd be more nice to see what others think they should be tbh, because i usually am not great at prioritization and often have bad ideas.... | 15:17:23 |
| Lily Foster | (i've also been a bit busy the past few weeks since the OC may have come during a, uh, life event.... but i'll have time again this weekend to get some of that going) | 15:20:05 |
 delroth | small stuff I'd like to see ofborg do better:
- better handle changes to NixOS modules: automatically run tests, notify maintainers
- properly mark errors as errors, not just "skipped" (which is easy to miss) - and yes, that means people will have to fix their broken/flaky tests
- maybe split off the eval to compute number of rebuilds into a separate async step, so that maintainers notification / builds / tests can start while that long eval step gets processed
larger stuff:
- merge queue for nixpkgs when :) or at least a way to auto-merge a PR once eval+builds+tests have completed and are successful
- auto nixpkgs-review-like rebuild of dependents for changes with few dependents, maybe same but with some sampling for changes that impact more derivations (smoke test, basically)
- figuring out a way to have a local testing setup for ofborg so contributions aren't limited to people with access to the infra (maybe via a public tee of webhooks events to handle dynamic public/anonymous subscribers, and a dry run mode that doesn't try to perform actions on github)
| 15:39:55 |
| delroth | since you're asking... :p | 15:40:05 |
| Lily Foster | The small stuff you listed and ability for mortals to run pieces of or all of ofborg locally are definitely pain points i'm looking at helping short-term. I appreciate you making the list β€οΈ | 15:42:31 |
| delroth | yeah I don't think anything here is groundbreaking :) | 15:43:49 |
| Lily Foster | (also local testing will let even people with infra access not have to test changes in prod π
) | 15:44:01 |
