| 2 Dec 2023 |
 @julienmalka:matrix.org | * Hello, I was discussing the other day with one of my advisors (Théo Zimmermann, who is a nixpkgs committer but not present here. He has been a release manager for the Coq project) about the difficulties we had for the release process this time, and he suggested a few improvements:
- During the branch-off, instead of doing changes to the release-branch, pushing and then also doing modifications to the master branch, he suggested we first open a PR to the master branch containing all the changes described in the
Back on the master branch section of the wiki. This can be done before the branch-off and kept as a draft. At the branch-off, we first merge that PR, then we can work on the release branch in peace, knowing exactly on which commit basing this branch. This way we ditch all the problems of the type "the master branch advanced while we were working on the release branch". We also do not have to push on master.
- He suggested that instead of using the branch protections feature, we switch to "branch rules". Apparently, they are more expressive than the branch protections, and also appear publicly on the repo: https://github.com/NixOS/nixpkgs/branches --> by going to that page and clicking on the little shield, you get a list of all the rules applying to the branch
| 13:17:12 |
| @julienmalka:matrix.org | * Hello, I was discussing the other day with one of my advisors (Théo Zimmermann, who is a nixpkgs committer but not present here. He has been a release manager for the Coq project) about the difficulties we had for the release process this time, and he suggested a few improvements:
- During the branch-off, instead of doing changes to the release-branch, pushing and then also doing modifications to the master branch, he suggested we first open a PR to the master branch containing all the changes described in the
Back on the master branch section of the wiki. This can be done before the branch-off and kept as a draft. At the branch-off, we first merge that PR, then we can work on the release branch in peace, knowing exactly on which commit to base this branch. This way we ditch all the problems of the type "the master branch advanced while we were working on the release branch". We also do not have to push on master.
- He suggested that instead of using the branch protections feature, we switch to "branch rules". Apparently, they are more expressive than the branch protections, and also appear publicly on the repo: https://github.com/NixOS/nixpkgs/branches --> by going to that page and clicking on the little shield, you get a list of all the rules applying to the branch
| 13:17:43 |
 raitobezarius | Can you send PRs to the release wiki? | 14:41:19 |
| raitobezarius | For the suggestion 2, this has to be seen with the GH org owners | 14:41:33 |
| @julienmalka:matrix.org | I can do that yes, wondering if people had feedback on these before I write a PR | 14:41:49 |
| raitobezarius | Well, 1 has been suggested multiple times but what matters is the detail of what you will wrote in the release wiki and if this is equivalent to the process we have or do we lose things by doing it this way | 14:42:10 |
| raitobezarius | infinisil did already suggest something similar to 1 (or even exactly 1) in the past but the PR is stalled because my comments about the various edgecases are not addressed yet. | 14:42:29 |
| @julienmalka:matrix.org | In reply to @raitobezarius:matrix.org
For the suggestion 2, this has to be seen with the GH org owners Sure, I don't know what is the most appropriate public place is to discuss that | 14:42:29 |
| raitobezarius | Here is probably fine but you need to @ a GH org owner | 14:42:42 |
| @julienmalka:matrix.org | In reply to @raitobezarius:matrix.org
infinisil did already suggest something similar to 1 (or even exactly 1) in the past but the PR is stalled because my comments about the various edgecases are not addressed yet. I'll read the PR, thanks | 14:43:18 |
 hexa | public rules sounds like an improvement | 15:13:49 |
| hexa | especially if they are more granular | 15:14:01 |
 infinisil | It's a fairly new github feature, I think it was in beta like a year ago | 15:14:52 |
| infinisil | Fully agreed that branch rules are better and we should switch to using them | 15:15:15 |
| 3 Dec 2023 |
 jonringer | The manual still needs to be updated with the release date: https://nixos.org/manual/nixos/stable/release-notes#sec-release-23.11 | 18:52:02 |
| jonringer |
Release 23.11 (“Tapir”, 2023.11/??)
| 18:52:21 |
 Vladimír Čunát | It's there, only lockfile needs updating:
https://github.com/NixOS/nixos-homepage/pull/1177 | 20:49:40 |
| 4 Dec 2023 |
 lennart | I do not really understand, what action is stopping us from having an up-to-date manual | 15:15:01 |
| lennart | * I do not really understand, what action is stopping us from having an up-to-date manual? :) | 15:15:04 |
| Vladimír Čunát | I think none of us have permission to merge in the homepage repo. (I don't at least.) | 15:46:01 |
| lennart | I'll poke grahamc and garbas | 15:48:15 |
 Ilan Joselevich (Kranzes) | I can | 16:17:08 |
| Ilan Joselevich (Kranzes) | What needs to be merged? | 16:17:23 |
 figsoda | I can as well, I just wasn't sure about merging it without any approvals | 16:18:09 |
| figsoda | I'll go ahead and merge this if it looks good to you | 16:18:40 |
| Ilan Joselevich (Kranzes) | I didn't look at it | 16:19:22 |
 Lily Foster | In reply to @figsoda:matrix.org
I'll go ahead and merge this if it looks good to you if it's that pr above, is the "temporary" pinning still needed? | 16:19:24 |
| Ilan Joselevich (Kranzes) | I trust yall, but yeah, please merge it yourself | 16:19:38 |
| figsoda | In reply to @lily:lily.flowers
if it's that pr above, is the "temporary" pinning still needed? good point, I don't think it's needed anymore, I'll change it to a regular update then | 16:20:42 |
| figsoda | merged | 16:26:26 |
