| 20 Nov 2023 |
 raitobezarius | * I would rather avoid polluting the GitHub repo itself with test data | 20:35:05 |
| raitobezarius | People often pull regularly nixpkgs with all the references | 20:35:12 |
| raitobezarius | They would grab the test data refs & git objects | 20:35:20 |
| raitobezarius | (People also complain about that) | 20:35:24 |
| raitobezarius | Also, we need to name that branch a certain name to test it | 20:35:52 |
| raitobezarius | We cannot name it "random" branch because not all the branches are protected | 20:36:00 |
| raitobezarius | So we would need to do release-TEST_DONOTUSE and test there for example | 20:36:16 |
 infinisil | How about figuring this out now, so that we can write down what works for the next release? | 20:37:15 |
| raitobezarius | I am not figuring this out, I am tired and this release cycle has been taking a lot of energy of myself, we had a lot of things to deal with and I would like to move any discussion regarding how to improve the release process to the retrospective that is dedicated to this type of issues | 20:37:47 |
| raitobezarius | * I am not figuring this out now, I am tired and this release cycle has been taking a lot of energy of myself, we had a lot of things to deal with and I would like to move any discussion regarding how to improve the release process to the retrospective that is dedicated to this type of issues | 20:37:51 |
| raitobezarius | People are free to prepare solutions for the problem but I honestly don't have it in me to plug on my brain to follow such a discussion now | 20:38:25 |
| 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 |
 VladimÃr ÄŒunát | 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 |
| VladimÃr ÄŒunát | One just needs to be careful with the steps, e.g. push new commits before creating a tag. | 06:05:58 |
| VladimÃr ÄŒunát | (to be sure that they won't need to be repased) | 06:06:20 |
| VladimÃr ÄŒunát | * (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 |
| VladimÃr ÄŒunát | 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 |
