| 1 Dec 2023 |
 figsoda | *it's still not in nixos-23.11 yet | 14:13:28 |
| figsoda | https://github.com/NixOS/nixos-homepage/pull/1177 | 14:32:00 |
 @julienmalka:matrix.org | figsoda: apparently people are confused that 23.11 is still marked as beta | 15:34:53 |
| @julienmalka:matrix.org | Is there a PR open to mark it as stable ? | 15:35:04 |
| figsoda | ah ha I will go ahead and merge https://github.com/NixOS/nixos-search/pull/707 | 15:35:26 |
| figsoda | this should be fixed in a few minutes | 15:35:40 |
| @julienmalka:matrix.org | Hmmm | 15:35:45 |
| @julienmalka:matrix.org | Is that really the right change ? Is there not a json file somewhere to edit | 15:36:00 |
| @julienmalka:matrix.org | Or it’s something else, I am just confused | 15:36:53 |
| figsoda | this essentially pulls in https://github.com/NixOS/nixos-org-configurations/pull/314 which marks 23.11 as stable. If you were referring to nixos search, this should be able to fix it | 15:37:03 |
| figsoda | it's live | 15:37:29 |
| figsoda | 
Download image.png | 15:37:29 |
| @julienmalka:matrix.org | Ah thank you, I was thinking of this file, but I understand now why updating the flake lock is fixing the issue :) | 15:37:55 |
 Lily Foster | In reply to @julienmalka:matrix.org
Is that really the right change ? Is there not a json file somewhere to edit i mean the flake lock is technically a json file that was edited (i am meaning this as a light-hearted joke, to be clear) | 15:38:38 |
| @julienmalka:matrix.org | To be clear what I meant was | 15:39:02 |
| @julienmalka:matrix.org | Is there not a something something to edit ? | 15:39:11 |
| figsoda changed the room topic to "23.11 "Tapir" | https://nixos.github.io/release-wiki/Home.html" from "23.05 "Stoat" | https://nixos.github.io/release-wiki/Home.html". | 15:39:54 |
 Ilan Joselevich (Kranzes) | Maybe update room's picture too? | 18:05:04 |
| Room Avatar Renderer. | 19:17:09 |
| 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) 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:16:32 |
| @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 |
