| 20 Nov 2023 |
 figsoda | Yeah the main issue is that the -23.11 branches had already diverged from master because the push is not | 20:18:54 |
| figsoda | In reply to @raitobezarius:matrix.org
figsoda: Can you reconvene a time for the next branch-off attempt? The same time (7pm UTC) works for me | 20:19:13 |
 raitobezarius | In reply to @infinisil:matrix.org
From what you told me though, the workflow in https://github.com/NixOS/release-wiki/pull/70 seems to be working though. It only doesn't work because of a mistake, which wasn't documented before. I already explained that this workflow is not equivalent to the previous one due to the absence of signing | 20:19:35 |
| raitobezarius | (+ the tag) | 20:20:11 |
| raitobezarius | Whether or not this works is not really relevant, being mistakes resilient or mistake undoable is also important for a workflow | 20:20:27 |
| raitobezarius | There's an infinite amount of workflows that could work | 20:20:40 |
| raitobezarius | But there's one we adopted before and new ones we could adopt and we didn't really adopt new ones because this one is not merged | 20:20:56 |
| raitobezarius | * But there's one we adopted before and new ones we could adopt and we didn't really adopt this new one because this one is not merged | 20:22:01 |
 infinisil | At least we can see now what works and what doesn't, it's kind of hard to test this otherwise. | 20:22:43 |
| raitobezarius | Either case, I hope this opportunity will enable us to be a bit more mindful about this type of situation because I kind of warned about those scenarios where things don't really behave as expected and this would create setbacks for ceremonial processes like branch-off | 20:23:16 |
| infinisil | I do hope that we don't end up in a situation where the branch protection settings need manual updates every release though | 20:23:33 |
| raitobezarius | It's a shame that we wasted the time of people who came for the branch-off process but anyway I am not a GitHub organization owner so I cannot unblock this. | 20:23:40 |
| raitobezarius | In reply to @infinisil:matrix.org
I do hope that we don't end up in a situation where the branch protection settings need manual updates every release though In that case, probably someone has to write the code to absolve any user to do mistakes during the processes | 20:24:03 |
| raitobezarius | So we get it always it right until there's any type of transient errors that get it wrong for us | 20:24:17 |
| raitobezarius | * So we get it always right until there's any type of transient errors that get it wrong for us | 20:24:22 |
| raitobezarius | But I don't think we can avoid the fact that mistakes are impossible to avoid and if we want to keep the security properties of having only single commit that signs the whole release, I'm not sure we can avoid scratching + recreating from a ceremonial perspective | 20:24:58 |
| infinisil | Even with a PR you can have a signed commit, it's just going to be part of a merge | 20:26:16 |
| raitobezarius | I agree with that | 20:27:06 |
| infinisil | Imo the release team shouldn't hesitate to make minor changes to the release process as necessary. Generally nobody else would do that | 20:29:20 |
| raitobezarius | Yep but PR workflow is not a minor change. | 20:29:35 |
| raitobezarius | It's a change that has to be discussed beforehand and merged before a release process starts | 20:29:48 |
| raitobezarius | We tried multiple minor modifications of the workflow during the branch-off to no avail because of the permissions set currently | 20:30:04 |
| infinisil | In reply to @raitobezarius:matrix.org
Yep but PR workflow is not a minor change. It sounds fairly minor to me 🤷 | 20:32:24 |
| raitobezarius | Sure, it didn't sound minor at that time to me, it doesn't sound minor neither for now | 20:32:43 |
| 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 |
