| 20 Nov 2023 |
 raitobezarius | So we cannot replicate the process on another "test" repo | 20:34:28 |
| raitobezarius | We would have to do it live | 20:34:32 |
 @julienmalka:matrix.org | Yes | 20:34:37 |
| @julienmalka:matrix.org | Is that not fine ? | 20:34:43 |
| @julienmalka:matrix.org | Trying to force push on a random test branch ? | 20:34:59 |
| raitobezarius | I would rather avoid polluting the GitHub itself with test data | 20:34:59 |
| 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 |
