| 22 Apr 2022 |
|  Linux Hackerman is moving: @linus:schreibt.jetzt left the room. | 07:40:10 |
 Vladimír Čunát | * Locally I was getting errors earlier during the build, as some of the compiler/linker steps apparently shot over the 4G memory limit. Maybe higher --cores or $(nproc) was causing it. | 08:08:49 |
| Vladimír Čunát | * Locally I was getting errors earlier during the build, as some of the compiler/linker steps apparently shot over 32-bit memory limits. Maybe higher --cores or $(nproc) was causing it. | 08:09:09 |
| Vladimír Čunát | Otherwise I'd have just disabled the test(s) on i686. | 08:09:59 |
 Artturin | In reply to @mic92:nixos.dev
Do we know how many users this target has? We could make a gh issue and Pin it | 11:43:38 |
| 23 Apr 2022 |
|  Amit Levy joined the room. | 03:05:44 |
| Vladimír Čunát | So I hacked around it for now (by platform-specific downgrade), and thus it's perhaps easy to keep it for 22.05, but it might be worth considering to drop after forking off (and thus for > 22.05). | 10:53:22 |
| Vladimír Čunát | BTW, having nixos.tests.zfs.installer.i686-linux in channel-blocking set seems really absurd. | 10:55:58 |
| 25 Apr 2022 |
 Mic92 | Agreed. zfs is not really suited for 32-bit let alone legacy x86 | 07:16:57 |
| 26 Apr 2022 |
| Artturin | Relevant to the release https://github.com/NixOS/nixpkgs/issues/170465 | 23:45:50 |
| 29 Apr 2022 |
|  lovek323 joined the room. | 01:09:17 |
| 30 Apr 2022 |
 cdepillabout | I have a question about the release process of 22.05. If I maintain a relatively leaf package (in this case, the PureScript compiler), and a new major version has just been released, am I currently allowed to bump purescript to the new version in Nixpkgs? From https://github.com/NixOS/nixpkgs/issues/165792, it looks like there are various periods where breaking changes are not allowed, but I wasn't sure which part of this process refers to the leaf packages that have few dependencies. | 04:19:10 |
| cdepillabout | * I have a question about the release process of 22.05. If I maintain a relatively leaf package (in this case, the PureScript compiler), and a new major version has just been released, am I currently allowed to bump the top-level purescript attribute to the new version in Nixpkgs? From https://github.com/NixOS/nixpkgs/issues/165792, it looks like there are various periods where breaking changes are not allowed, but I wasn't sure which part of this process refers to the leaf packages that have few dependencies. | 04:31:36 |
| Vladimír Čunát | In reply to @cdepillabout:matrix.org
I have a question about the release process of 22.05. If I maintain a relatively leaf package (in this case, the PureScript compiler), and a new major version has just been released, am I currently allowed to bump the top-level purescript attribute to the new version in Nixpkgs? From https://github.com/NixOS/nixpkgs/issues/165792, it looks like there are various periods where breaking changes are not allowed, but I wasn't sure which part of this process refers to the leaf packages that have few dependencies. I believe that's the "Restrict all breaking changes" (except desktop managers) tomorrow. After that you could add a new version without switching the default. | 06:14:39 |
| cdepillabout | In reply to @vcunat:matrix.org
I believe that's the "Restrict all breaking changes" (except desktop managers) tomorrow. After that you could add a new version without switching the default. Ah, thanks. In the Branches Affected column, only staging and staging-next are listed, so I thought that maybe that's only for the "large" changes that affect many packages. | 06:41:09 |
| cdepillabout | In reply to @vcunat:matrix.org
I believe that's the "Restrict all breaking changes" (except desktop managers) tomorrow. After that you could add a new version without switching the default. * Ah, thanks. In the Branches Affected column, only staging and staging-next are listed for "Restrict all breaking changes", so I thought that maybe that's only for the "large" changes that affect many packages. | 06:41:41 |
| Vladimír Čunát | Oh right. Maybe I'm wrong 🤷 | 06:41:44 |
| Vladimír Čunát | Anyway, if it's about a leaf package that isn't that much popular, I think the decision shifts more to maintainers of that package. | 06:50:53 |
| cdepillabout | Oh okay, that makes sense then. | 08:24:36 |
 Janne Heß | In reply to @cdepillabout:matrix.org
Ah, thanks. In the Branches Affected column, only staging and staging-next are listed for "Restrict all breaking changes", so I thought that maybe that's only for the "large" changes that affect many packages. Yeah you are right, for some reason we never restrict breaking change son master (unless you interpret "Focus on minimizing regressions in PRs targeting master" as such) | 09:48:51 |
| cdepillabout | In reply to @janne.hess:helsinki-systems.de
Yeah you are right, for some reason we never restrict breaking change son master (unless you interpret "Focus on minimizing regressions in PRs targeting master" as such) Ah, that's good to know. Thanks for the clarification. | 13:08:05 |
 Sandro | I always understand that rule that for example we shouldn't merge a bigger gcc update right now that is most likely going to break packages which need fixup. So risky changes need to wait a few weeks. | 14:48:55 |
| Sandro | In reply to @cdepillabout:matrix.org
I have a question about the release process of 22.05. If I maintain a relatively leaf package (in this case, the PureScript compiler), and a new major version has just been released, am I currently allowed to bump the top-level purescript attribute to the new version in Nixpkgs? From https://github.com/NixOS/nixpkgs/issues/165792, it looks like there are various periods where breaking changes are not allowed, but I wasn't sure which part of this process refers to the leaf packages that have few dependencies. Is Purescript pretty isolated and does not affect bigger things and then require bigger cleanups last minute from other people? If you can answer the question with a good feeling with yes I personally would just go for it. The rule is more about we shouldn't merge a gnome 42 update right now or change python3 to 3.10 or merge more risky things. | 14:52:21 |
| Vladimír Čunát | With Gnome and Plasma it's the other way, they have a positive exception. | 15:08:42 |
| Vladimír Čunát | IIRC one of the points for moving .03+.09 to .05+.11 was to align with their release cycle and always get them new. | 15:09:46 |
 jonringer | In reply to @vcunat:matrix.org
IIRC one of the points for moving .03+.09 to .05+.11 was to align with their release cycle and always get them new. Yes, it was :) | 15:54:46 |
| jonringer | instead of trying to cut a tag just before the stable release, we would have about a month for the stable release to be adopted | 15:55:10 |
| jonringer | In reply to @janne.hess:helsinki-systems.de
Yeah you are right, for some reason we never restrict breaking change son master (unless you interpret "Focus on minimizing regressions in PRs targeting master" as such) I didn't think that restricting master was necessary, if regressions are introduced, then they are easy to revert or address. Staging is a concern because it has a very long timeline for fixing regressions. | 15:56:24 |
| jonringer | * instead of trying to cut a stable nixos tag just before the DE stable release, we would have about a month for the DE stable release to be adopted into master | 15:56:52 |
| 1 May 2022 |
| cdepillabout | Sandro jonringer Thanks for the additional clarifications. In the case of PureScript, it is basically a leaf package with only one dependency, so it seems like merging into master is reasonable. | 02:17:28 |
