| 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 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 |
| jonringer | Sounds good to me | 02:18:33 |
| 2 May 2022 |
|  evax joined the room. | 09:08:33 |
| 4 May 2022 |
|  An exploring bot joined the room. | 15:02:28 |
| An exploring bot left the room. | 15:02:30 |
| 7 May 2022 |
 tomberek | Janne Heß: Apologies, I've been a bit out of the loop so far for this release. But it seems you've been on top of things and monitoring staging efforts. Have we scaled up Hydra? | 16:03:28 |
| Vladimír Čunát | In reply to @tomberek:matrix.org
Janne Heß: Apologies, I've been a bit out of the loop so far for this release. But it seems you've been on top of things and monitoring staging efforts. Have we scaled up Hydra? No scaling so far, I believe. | 16:13:41 |
| Vladimír Čunát | Except for upgrading the central machine recently, mainly due to running OOM on channel updates. | 16:14:40 |
| Vladimír Čunát | In reply to @tomberek:matrix.org
Janne Heß: Apologies, I've been a bit out of the loop so far for this release. But it seems you've been on top of things and monitoring staging efforts. Have we scaled up Hydra? * No scaling so far, I believe. (and I haven't heard of such plans) | 16:16:29 |
| tomberek | I've tried to get some scale-up during ZHF to accommodate the higher rate of turnover: https://github.com/NixOS/nixos-org-configurations/issues/186 | 16:20:34 |
| Vladimír Čunát | I think that will be mainly relevant for the period between branch-off and retiring 21.11 (i.e. June, basically). | 16:59:26 |
| Vladimír Čunát | Especially if some mass-rebuild critical fixes appear. | 16:59:59 |
| Janne Heß | Yeah I forgot about that. I'll text Graham | 17:04:54 |
