| 11 Jan 2025 |
 hexa | * https://github.com/vim/vim/security/advisories/GHSA-5rgf-26wj-48v8 vim Philip Taron (UTC-8) | 16:24:52 |
 Philip Taron (UTC-8) | On it | 16:28:08 |
| Philip Taron (UTC-8) | Will still be a staging PR due to number of rebuilds (all vim plugins) | 16:29:19 |
| Philip Taron (UTC-8) | * Will still be a staging PR due to number of rebuilds (all vim plugins) also because IMO these vulns for code editing are only so bad | 16:29:49 |
| hexa | the commit looks fairly straightforward to backport into staging-24.11 | 16:30:34 |
| hexa | * the commit looks fairly straightforward to backport into staging-24.11 | 16:30:43 |
| 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 |
