| 13 Sep 2024 |
 clason | It's just important to somehow link the manual backport to the original PR (obviously) in the description. | 07:44:47 |
 tris203 | Well described. Exactly. If it's documented that this is the process and that the manual backport PR should reference the original one. Then even the tidy up becomes relatively simple. | 07:46:34 |
|  ortolanbunting3002 joined the room. | 10:32:10 |
 dundargoc | In reply to @clason:matrix.org
The proposal is to change step 4 as follows:
4. workflow slaps a needs:backport label on it
5. look for closed PRs with the label (simple filtered view)
6. manually create a backport PR and remove the label Hmm, OK, let's give it a try then. | 12:07:10 |
| dundargoc | I still have some doubts on how useful this is gonna be but I still wanna give it a shot. | 12:08:00 |
| dundargoc | Worst case is we remove it if it doesn't work out anyway | 12:08:18 |
| clason | I think this is going to be useful because then
every possible state is queryable via labels.
| 12:09:35 |
| dundargoc | Yes, but someone would still need to remember to check the label in the first place. Out of sight often means out of mind. | 12:11:07 |
| clason | (it's much easier to remove a label that is not needed (anymore) than to later add a label that is -- for the former you can look at all labeled prs, but for the latter you need to look at all prs, which is a lot more) | 12:11:12 |
| dundargoc | * Yes, but someone would still need to remember to check the label in the first place. | 12:11:14 |
| clason | In reply to @fundar:matrix.org
Yes, but someone would still need to remember to check the label in the first place. Yes but now someone already has to remember to check the unlabelled merged prs. That's a lot harder. | 12:11:46 |
| dundargoc | I guess that is true | 12:12:33 |
| clason | That could be us before a release ("have all fixes been backported?") or padawans/new contributors looking for a "good first issue" (which this would be, for a change) | 12:12:40 |
| clason | It just gives us an additional tool to find them. | 12:13:15 |
| dundargoc | Justin has a checklist issue but only for major releases, and for those backporting shouldn't be needed. | 12:13:36 |
| dundargoc | I guess we could add a "remove all needs:backport labels" since these can be reset on each major releases | 12:14:00 |
| dundargoc | * I guess we could add a "remove all needs:backport labels" since these can be reset on each major release | 12:14:02 |
| dundargoc | Uh, sorry. Minor. I keep mixing up major/minor for neovim | 12:14:12 |
| clason | I don't think we need a formal checklist for that; backporting fixes is the core reason for a point release, so looking at backports is integral part of considering a point release. | 12:14:40 |
| dundargoc | Yeah fair | 12:15:13 |
| clason | In reply to @fundar:matrix.org
I guess we could add a "remove all needs:backport labels" since these can be reset on each major release We might still want to put out a point release after a minor release. (We haven't so far because of time constraints, but as Neovim stabilizes, keeping support for the previous version is a good practice -- say, until the first point release of the new version.) | 12:16:22 |
| clason | Anyway, that's getting neck deep into hypotheticals now. | 12:16:38 |
| dundargoc | Yeah lol | 12:17:02 |
| clason | Again, the main point is that obsolete labels are a much smaller problem than finding needles in an unlabeled haystack | 12:17:07 |
| dundargoc | Makes sense. | 12:17:18 |
| clason | Anyway, not high priority; if this is complicated to implement using our existing labeler, we can leave it until the action has native support for it. | 12:23:47 |
| dundargoc | This is very easy to implement unless I missed a crucial detail somewhere. | 12:24:32 |
| dundargoc | I will work on that once I'm ready with the current PR | 12:25:00 |
| clason | https://github.com/neovim/neovim/actions/runs/10850459961/job/30111958820 | 14:25:35 |
| clason | probably needs an if successful check on the automerge ;) | 14:25:54 |
