| 20 Nov 2023 |
 infinisil | Like, instead of pushing the beta commit directly in the initial branch version, make a PR for that instead, this way you can force push to the PR to update it as necessary | 20:33:00 |
 raitobezarius | The problem is not really in how many ways we can describe this workflow, it is that it's not on the release wiki as clear instructions for release managers | 20:33:27 |
| raitobezarius | This is a process documentation problem, not a process in itself problem | 20:33:35 |
| raitobezarius | If you follow a certain process documentation, you cannot switch to a different type in the middle | 20:33:45 |
| raitobezarius | The whole process has to be written taking into account the new type of workflow you are doing | 20:33:54 |
| raitobezarius | As this is not the case for the time being, this is not a minor change because you can find yourself in the middle of an incompatible step | 20:34:05 |
 @julienmalka:matrix.org | Why did we not test the workflow changes before ? | 20:34:08 |
| raitobezarius | In reply to @julienmalka:matrix.org
Why did we not test the workflow changes before ? Because we don't have access to the permission data of the GitHub repository | 20:34:20 |
| 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 |
