 | Neovim dev | 203 Members |
| Discussion about Neovim development and adjacent topics | 14 Servers |
| Neovim dev | 203 Members |
| Discussion about Neovim development and adjacent topics | 14 Servers |
| Sender | Message | Time |
|---|---|---|
| 11 Sep 2024 | ||
 justinmk | In reply to @mariasolos:matrix.orga WASM LSP client seems like an awesome idea. then any ide/editor that can load the wasm library only has to talk to a library instead of dealing with lsp protocol. | 08:14:04 |
 clason | "now you have two problems" ;) | 08:15:06 |
| justinmk | this is also something we wanted to do for Nvim RPC: provide a single libnvim client that could be imported by ruby/python/etc, so then you don't need to implement RPC in ruby/python/etc. | 08:15:19 |
| justinmk | * this is also something we wanted to do for Nvim RPC: provide a single libnvim client that could be imported by ruby/python/etc, so then you don't need to implement msgpack-RPC in ruby/python/etc. | 08:16:19 |
 tris203 | dundargoc: thoughts on a adding a "ci:backport" failed label? https://github.com/korthout/backport-action/issues/211#issuecomment-1398603738 | 15:19:58 |
| tris203 | * dundargoc: thoughts on a adding a "ci:backport failed" label? https://github.com/korthout/backport-action/issues/211#issuecomment-1398603738 | 15:20:18 |
| 12 Sep 2024 | ||
| justinmk | In reply to @gpanders:matrix.orgis it useful that all the UIs are suspended, or would it be better if only the current UI is suspended? I think we could direct the suspend event to target only the "current" TUI | 12:05:51 |
 gpanders | In reply to @justinmk2:matrix.orgI think just current makes sense | 12:27:33 |
| justinmk | cool | 12:33:14 |
 dundargoc | In reply to @tris203:matrix.orgSure. What's the usecase? Just to make it easier to track which backports haven't been done? | 23:00:24 |
| dundargoc | Wait, it'd need another name. ci: prefix is for labels that actually do something. Anything else is fine. | 23:00:53 |
| tris203 | In reply to @fundar:matrix.orgExactly that. I don't mind manually fixing any that fail. But it would be helpful if I could scan which ones need doing | 23:01:19 |
| dundargoc | Uh, just do it on the spot tbh? | 23:02:27 |
| dundargoc | I doubt this will be that useful tbh, but I don't mind implementing it | 23:03:03 |
| dundargoc | Or reviewing it if someone else wants to go for it | 23:03:16 |
| tris203 | It's just that at the moment. The only way to know that a ci backport failed it from the comment. Which is a bit arbitrary without going into each PR | 23:04:05 |
| dundargoc | But you don't know which failed backports are yours and which are others | 23:05:04 |
| dundargoc | Idk, I suspect this is gonna scale badly and add extra bookkeeping since we'll need to unlabel the marked PRs we have manually decided to backport | 23:10:31 |
| dundargoc | Redacted or Malformed Event | 23:32:38 |
| 13 Sep 2024 | ||
| clason | Nah, I think this is a (small) net positive | 06:25:53 |
| clason | Although the label will be on closed PRs, which makes it even less visible | 06:26:24 |
| clason | (and you're right, you'll have to unlabel manually) | 06:26:38 |
| clason | (label could be needs:backport or needs:manual-backport) | 06:26:57 |
 yee haw joined the room. | 06:46:45 | |
| clason | In reply to @fundar:matrix.orgThat's not the point; I think they are offering to take care of manual backporting generally. (Which, to be fair, is a pretty good way of getting familiar with the codebase.) | 07:29:14 |
| clason | In reply to @fundar:matrix.org Not quite, the workflow is
| 07:37:37 |
| clason | It's the last step that is the most onerous, since you either have to pay attention to the notifications or -- even worse -- manually go through all closed PRs labeled ci:backport to see if any have the "backport failed" comment -- and then check other open and closed PRs to see if someone else has already done it. | 07:39:17 |
| clason | The proposal is to change step 4 as follows: 4. workflow slaps a needs:backport label on it5. look for closed PRs with the label (simple filtered view) 6. manually create a backport PR and remove the label | 07:40:59 |
| clason | This seems to me a smoother workflow; in particular, we no longer have to worry about missing a backport since now every possible state is queryable via labels. | 07:42:56 |
| clason | (Might want to note that somewhere in MAINTAIN and/or CONTRIBUTING.) | 07:43:30 |