| 20 Nov 2023 |
 raitobezarius | We could just scrap off the whole branch and restart it | 20:16:30 |
| raitobezarius | We are not saying to force push on master to be clear | 20:16:36 |
 infinisil | In reply to @raitobezarius:matrix.org
We could just scrap off the whole branch and restart it I don't think you can delete it | 20:16:52 |
| raitobezarius | No, we cannot because of the hook | 20:17:02 |
| raitobezarius | We could before the changes, though. | 20:17:06 |
| raitobezarius | We could say that next time force push has to be restrained but someone has to write the new instructions | 20:17:14 |
| raitobezarius | And PR the new workflow | 20:17:18 |
| raitobezarius | In reply to @figsoda:matrix.org
I don't think I tried to delete the tag from the CLI, I was going to search it because I could never remember the command, but I realized I could just use the web UI I think I tried and it failed but maybe I also failed to do it properly; regardless, too much divergence from the handbook is not good | 20:17:49 |
| raitobezarius | figsoda: Can you reconvene a time for the next branch-off attempt? | 20:18:21 |
| raitobezarius | For tomorrow? | 20:18:24 |
| infinisil | 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. | 20:18:47 |
 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 |
