| 20 Nov 2023 |
 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 |
 @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 |
