| 26 Sep 2025 |
|  tornax joined the room. | 08:51:24 |
| 27 Sep 2025 |
|  BerriJ joined the room. | 12:12:47 |
|  yapxuan joined the room. | 20:21:53 |
| 28 Sep 2025 |
| tornax | Hi! May I ask if the new crowdsec module may not be added to stable for the next release (yet) please? It feels like as if there is still some work to do (https://github.com/NixOS/nixpkgs/pull/446307). So I'd like to keep its config as unstable for the time being. | 19:08:33 |
| tornax | * Hi! May I ask if the new crowdsec module may not be added to stable for the next release (yet) please (just in case if that's going to happen)? It feels like as if there is still some work to do (https://github.com/NixOS/nixpkgs/pull/446307). So I'd like to keep its config as unstable for the time being. | 19:08:55 |
 Vladimír Čunát | If you keep the PR as draft until the 25.11 fork-off happens... | 19:54:49 |
| 29 Sep 2025 |
 Sandro | It is technically not possible to exclude the module from the release unless we remove it again.
But I don't see a problem backporting the fix PR whenever it is ready. | 13:25:01 |
|  @brian:bmcgee.ie left the room. | 13:40:19 |
 leona | This depends a bit on how the fix PR actually works. For it to be backportable, it would be good to allow for a seamless transition | 15:39:02 |
| leona | but also it's correct what Sandro said, that there is no technical possibility to remove the module from the release. We could ofc remove the module directly after branch-off, but this also feels a bit strange | 15:39:43 |
| Sandro | The module is pretty new and so far it does not really work out of the box. So I would just say that it is fine to Backport even if it is breaking. Just my opinion though. | 15:41:27 |
| 30 Sep 2025 |
|  Lun joined the room. | 14:01:39 |
| 2 Oct 2025 |
 jficz | Hi! What can I do to have this mautrix-whatsapp module backport PR merged? https://github.com/NixOS/nixpkgs/pull/446155
It's manual because of merge conflicts but otherwise equal to the original PR. | 19:29:33 |
 SigmaSquadron | Would it be possible to cherry-pick the original commits instead of making new ones? | 22:23:01 |
| jficz | In reply to @sigmasquadron:matrix.org
Would it be possible to cherry-pick the original commits instead of making new ones? That's what the bot tried to do but failed because of conflicts. I don't think it's possible to do it cleanly. | 22:35:24 |
| SigmaSquadron | You should still cherry-pick manually and edit the cherry-picks. | 22:45:07 |
| 3 Oct 2025 |
| jficz | ok, I'll try again but I did exactly that I believe (as suggested here, except yes, I somehow managed to base it against master so I rebased against release after that) | 20:57:29 |
| jficz | * ok, I'll try again but I did exactly that I believe (as suggested here, except yes, I somehow managed to base it against master at first so I rebased against release after that) | 20:58:43 |
|  moleksiak joined the room. | 23:30:58 |
| 4 Oct 2025 |
 dish [Fox/It/She] | Something to consider for now/future releases: Something a la the "Release Blockers" thread, but for things that are intended to be cleaned up post-branchoff. I've found a lot of stuff that was intended to be removed in 25.05 or 25.11, but hasn't been yet, so having a central place to track those sorts of things, so that there's a single checklist of items would be good. Obviously, maintainers of packages would be the ones adding things to it, but it's something to think about for the future, maybe? | 02:28:45 |
| leona | it might be, otherwise I don't know how helpful a tracking issue would be. We already have the label 2.status: wait for branch-off for PRs and issues that are blocked. I feel like a tracking issue is only really helpful when multiple people (and not just the maintainers of the respective module or package) can work on the issues. But also just my idea
Personally, I more like the idea for reducing the time where breaking changes are restricted by branching off earlier, but this would possibly require more energy and especially Hydra capacity, that we currently don't have. This idea was already mentioned last release cycle by multiple people, but IMO currently not actionable
| 07:45:33 |
| dish [Fox/It/She] | i mean multiple people could work on the issues or pull requests, but most things are just marked with comments and you need to search through the code to find stuff, since most likely it gets forgotten | 15:34:19 |
| 6 Oct 2025 |
|  tallyho-dulcet joined the room. | 09:16:41 |
|  felix joined the room. | 12:52:18 |
| 7 Oct 2025 |
| Vladimír Čunát | Ideally we'd cut the breaking changes to release-critical packages now already, not moved to the weekend. | 15:11:53 |
| Vladimír Čunát | Or leave them to more careful approval. | 15:12:36 |
| Vladimír Čunát | But I think most of the relevant people know staging-next + release scheduling and the need to get breaking changes early. | 15:13:10 |
| Vladimír Čunát | * But I think most of the relevant people know staging-next + release scheduling and the need to get breaking changes early anyway. | 15:13:14 |
| leona | For me this would be fine. As far as I understood it, most people just wanted to move breaking changes to non release critical packages further back. But I leave that also up to jopejoe1 | 15:14:10 |
|  alunduil changed their profile picture. | 23:11:54 |
