| 11 Oct 2025 |
|  midischwarz12 joined the room. | 21:00:52 |
| 12 Oct 2025 |
| midischwarz12 removed their profile picture. | 02:45:02 |
| midischwarz12 set a profile picture. | 02:45:11 |
|  vivekanandan_ks set a profile picture. | 17:57:31 |
|  @midirhee12:tchncs.de removed their profile picture. | 21:27:45 |
| @midirhee12:tchncs.de removed their display name midirhee12. | 21:28:18 |
| @midirhee12:tchncs.de left the room. | 21:28:29 |
| 18 Oct 2025 |
|  dotlambda joined the room. | 01:43:11 |
| dotlambda | Where can I find the definition of "release critical packages"? | 01:43:45 |
 jopejoe1 | We currently track the definition and which ones it applies to on https://nixos.github.io/release-wiki/Release-Critical-Packages.html#list-of-release-critical-packages | 01:49:53 |
 vcunat | It would be best if the release schedule had a hyperlink to that page. | 06:32:37 |
| vcunat | * It would be best if the release schedule had a hyperlink to that definition. | 06:32:42 |
| 19 Oct 2025 |
|  @azahi:azahi.cc left the room. | 15:47:00 |
| 22 Oct 2025 |
|  raphi-debug joined the room. | 10:07:30 |
| 23 Oct 2025 |
|  @corite:x-hain.de left the room. | 05:13:14 |
|  adam (moved to @adam:matrix.system72.dev) joined the room. | 13:10:42 |
 emily | leona: jopejoe1: are we okay giving a freeze exemption to breaking changes that only affect override interfaces of specific packages, within the next ~week?
my feeling is that it should be fine, because we generally don't give very strong stability guarantees to override interfaces in general – e.g. every time we backport a version bump that drops a no-longer-used dependency we break override interfaces on stable
context is https://github.com/NixOS/nixpkgs/pull/445668 and possibly https://github.com/NixOS/nixpkgs/pull/453948
(the former is zero rebuilds and only changes override interfaces, though there will be a follow-up clean-up on staging that will cause rebuilds and slightly change the meaning of e.g. llvmPackages.override on Darwin, but it needs a few more changes before it's ready to land so checking re: the deadline)
| 15:42:23 |
 leona | Looks fine to me. Additionally, I like this effort too :) | 15:47:26 |
| jopejoe1 | I don't remember us ever having any grantu for the overriding interface and see it more of an unstable interface with a use at your risk level of support. | 15:50:42 |
| emily | I think there are some withFoo flags I would consider stable-ish API, but yeah, in general it breaks pretty often | 15:52:42 |
| emily | a more unified override interface with a clearer delineation between "monkey-patching with no stability guarantees" and "public API offered by packages to their users with the usual stability assurances" is something I would really like and have been doing design work on | 15:53:24 |
| emily | but that's definitely not for 25.11 :) | 15:53:31 |
| 28 Oct 2025 |
|  Robbie Buxton joined the room. | 19:19:17 |
| 30 Oct 2025 |
 dish [Fox/It/She] | in #452544 we added an option but it was decided it would be best to do a revert before release since the maintainers have an idea for a better interface. Since this is a new option that was added and it's not in a release yet, would this be okay to revert, given that breaking changes are not allowed at this point in time? | 20:28:48 |
| dish [Fox/It/She] | in #452544 there was an environmentFile option added to services.actual but it was decided it would be best to do a revert before release since the maintainers have an idea for a better interface. Since this is a new option that was added and it's not in a release yet, would this be okay to revert, given that breaking changes are not allowed at this point in time? | 20:29:10 |
| dish [Fox/It/She] | I believe it would be fine since it's not in a release yet, but just wanted to get a double-check | 20:29:29 |
| leona | i'd say that you can still remove it, as it's a edge package and the option only existed for such a limited time | 20:30:18 |
| dish [Fox/It/She] | gotcha, will let folks know. Thank you! | 20:30:46 |
| leona | like IMO the freeze period has two goals
- restricting large impact/risk changes so that we have a good and high quality release
- Make it easier for people to prepare their downstream work to to make the switch to the next release easier
both isn't really applicable for this change, so this is fine for me
| 20:33:38 |
| leona | so if the option would've been introduced like 3 months back, I would be a bit more hesitant | 20:34:19 |
