| 20 Nov 2023 |
 infinisil | Fair enough, thanks for the work! And sorry for being part of the reason for breaking the process 😅 | 20:38:44 |
 raitobezarius | It's fine, thank you for your work too, well, you did what you believed was good for the greater good in nixpkgs :) | 20:39:13 |
 @julienmalka:matrix.org | The last 2 times I've assisted the branch-off for a release, we've add the problem of master advancing during the release process, which creates a lot of confusion and make the RM have to start some part of the process again. Given that we have access to a github org owner (which should probably be good, or maybe RMs should be github org owners), we can make the master branch read-only during the branch-off to avoid PRs being merged to master. If people think that could be a good idea, I can investigate the exact consequences of that and do a few tests to sea if that is a feasible option. | 22:12:53 |
| @julienmalka:matrix.org | * The last 2 times I've assisted the branch-off for a release, we've add the problem of master advancing during the release process, which creates a lot of confusion and make the RM have to start some part of the process again. Given that we have access to a github org owner (which should probably be good), or maybe RMs should be github org owners), we can make the master branch read-only during the branch-off to avoid PRs being merged to master. If people think that could be a good idea, I can investigate the exact consequences of that and do a few tests to sea if that is a feasible option. | 22:14:56 |
| @julienmalka:matrix.org | * The last 2 times I've assisted the branch-off for a release, we've add the problem of master advancing during the release process, which creates a lot of confusion and make the RM have to start some part of the process again. Given that we have access to a github org owner (which should probably be good), or maybe RMs should be github org owners), we can make the master branch read-only during the branch-off to avoid PRs being merged to master. If people think that could be a good idea, I can investigate the exact consequences of that and do a few tests to see if that is a feasible option. | 22:15:06 |
| @julienmalka:matrix.org | * The last 2 times I've assisted the branch-off for a release, we've add the problem of master advancing during the release process, which creates a lot of confusion and make the RM have to start some part of the process again. Given that we have access to a github org owner (which should probably be good, or maybe RMs should be github org owners), we can make the master branch read-only during the branch-off to avoid PRs being merged to master. If people think that could be a good idea, I can investigate the exact consequences of that and do a few tests to see if that is a feasible option. | 22:15:33 |
| raitobezarius | I think it'd be fun to succeed making it read only | 22:44:17 |
| raitobezarius | But honestly I think that having a script that exploits a time window where you can finally push should probably the way to go IMHO | 22:44:35 |
| 21 Nov 2023 |
| infinisil | Taking a closer look at the release notes, I'm noticing they've become rather disorganised. I'm thinking of cleaning it up a bit | 03:20:53 |
| infinisil | I'll probably start by just writing release notes for lib, that won't conflict with anything | 03:55:00 |
 @alejandrosame:matrix.org | In reply to @infinisil:matrix.org
Taking a closer look at the release notes, I'm noticing they've become rather disorganised. I'm thinking of cleaning it up a bit lennart: and me will meet tomorrow to discuss and split the work to edit them now that they have stabilized and we are close to the actual release. | 04:52:28 |
| infinisil | alejandrosame: Nice! | 04:53:32 |
| infinisil | alejandrosame: raitobezarius: lib release notes: https://github.com/NixOS/nixpkgs/pull/268871 | 05:30:36 |
 vcunat | In reply to @julienmalka:matrix.org
The last 2 times I've assisted the branch-off for a release, we've add the problem of master advancing during the release process, which creates a lot of confusion and make the RM have to start some part of the process again. Given that we have access to a github org owner (which should probably be good, or maybe RMs should be github org owners), we can make the master branch read-only during the branch-off to avoid PRs being merged to master. If people think that could be a good idea, I can investigate the exact consequences of that and do a few tests to see if that is a feasible option. IIRC we changed the wiki so that this wouldn't be a problem anymore. | 06:05:33 |
| vcunat | One just needs to be careful with the steps, e.g. push new commits before creating a tag. | 06:05:58 |
| vcunat | (to be sure that they won't need to be repased) | 06:06:20 |
| vcunat | * (to be sure that they won't need to be rebased) | 06:06:22 |
| @julienmalka:matrix.org | Well we had the issue yesterday anyway | 07:03:22 |
| vcunat | I was too tired yesterday to attend, so you should know better than me. We might've missed something the last time. | 07:07:09 |
| raitobezarius | heads up figsoda alejandrosame (@riotbib is not in this channel?) we have been re-subscribed to all activities in nixpkgs following a changes in the permissions | 08:40:56 |
| raitobezarius | my notifications makes no sense | 08:41:02 |
 lennart | ah | 08:41:10 |
| lennart | (I am @riotbib :) ) | 08:41:16 |
| lennart | thanks for the heads-up | 08:41:43 |
| raitobezarius | for some reason matrix is stupid and didn't let me highlight you | 09:00:16 |
| raitobezarius | sorry for that | 09:00:19 |
| lennart | easy :) | 09:00:31 |
| lennart | (well I was riotbib, but am lennart now :D) | 09:00:47 |
| vcunat | @jtojnar thinks (see #gnome:nixos.org) that the branch is sufficiently stable to merge into nixpkgs master and 23.11. I prodded Hydra to start creating the remaining binaries for that, as it didn't have much to do anyway right now. | 09:53:20 |
| vcunat | * @jtojnar thinks (see #gnome:nixos.org) that the gnome branch is sufficiently stable to merge into nixpkgs master and 23.11. I prodded Hydra to start creating the remaining binaries for that, as it didn't have much to do anyway right now. | 09:53:41 |
