| 11 Jan 2025 |
 Philip Taron (UTC-8) | I have no problem with backporting the whole editor (patch versions fit into the release branch backports straightforwardly) | 16:31:19 |
| Philip Taron (UTC-8) | * I have no problem with backporting the whole editor to staging-24.11 (patch versions fit into the release branch backports straightforwardly) | 16:31:31 |
 hexa | if you can ensure there are no breaking changes in there 🙂 | 16:31:52 |
| Philip Taron (UTC-8) | I'll look through the commits. | 16:37:02 |
| Philip Taron (UTC-8) | https://github.com/NixOS/nixpkgs/pull/372980 | 16:42:56 |
|  oak 🏳️🌈♥️ changed their profile picture. | 16:45:21 |
| oak 🏳️🌈♥️ removed their profile picture. | 16:46:24 |
| oak 🏳️🌈♥️ set a profile picture. | 16:46:55 |
| Philip Taron (UTC-8) | https://github.com/NixOS/nixpkgs/pull/372981 (still reading through the commits) | 16:51:09 |
| hexa | that is not a valid backport | 16:51:51 |
| hexa | * that is not a valid backport that fits contributing.md | 16:51:57 |
| Philip Taron (UTC-8) | tell me more | 16:52:11 |
| hexa | backports need to be cherry-picks from master if possible | 16:52:40 |
| hexa | https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#manually-backporting-changes | 16:53:23 |
| hexa | * backports need to be cherry-picks from master if applicable | 16:54:04 |
| Philip Taron (UTC-8) | I'm happy to do whatever. I'll note that none of that mentions staging. The last PRs I've made against release branches have all been in this form, since they had to go to staging, and cherry-picking/rebasing was the order of the day. | 16:54:46 |
| hexa | with how you're currently doing it you are also bypassing the cherry-pick check 😄 | 16:57:59 |
| hexa | * with how you're currently doing it you are also bypassing the cherry-pick check, because it can't find any references to commits on master/staging/... 😄 | 16:58:19 |
| Philip Taron (UTC-8) | Again, happy to do whatever, but I literally cherry-picked the PR commit on top of the staging-24.11 branch. If there's a built-in delay before a PR can be opened against a release branch for security issues, in the immortal words of a certain president, "I'm learning about it right now! Amazing!"
I have to go do weekend stuff now, so I'll leave merging/editing/rejecting in all y'all's hands until the evening. | 17:05:02 |
| hexa | the master PR is vim: 9.1.0990 -> 9.1.1006 #372980 | 17:05:55 |
| hexa | the 24.11 pR is vim: 9.1.0787 -> 9.1.1006 #372981 | 17:06:02 |
| hexa | so you're hiding at least the 9.1.0787 -> 9.1.0990 commit | 17:06:16 |
| hexa | * the 24.11 PR is vim: 9.1.0787 -> 9.1.1006 #372981 | 17:06:23 |
| Philip Taron (UTC-8) | I'm still super confused. During the cherry-pick process, I edited the staging commit's description from 9.1.0990 to 9.1.0787 (since when applied on staging-24.11, that's the version it would be upgrading.) Is the assumption that release branches get the full set of PRs backported?! | 17:08:44 |
| hexa | each individual intermediate commit, yeah | 17:09:43 |
| Philip Taron (UTC-8) | Ok, I think I understand. | 17:12:00 |
| Philip Taron (UTC-8) | * Ok, I think I understand. I picked the intermediate commits too. | 17:13:24 |
| hexa | let's continue on the PR | 17:16:10 |
| 12 Jan 2025 |
|  @strutztm:strutztm.de joined the room. | 00:24:58 |
| 13 Jan 2025 |
 Niklas Korz | Not sure if these are the same that were fixed in vaultwarden 1.32.7 three weeks ago:
https://chaos.social/@fbausch/113821745299078611 | 15:28:46 |
