| 13 Mar 2026 |
 Ramses 🇵🇸 | There is a commit on -next that goes go_1_24 -> go because 1.24 is EOL, and another on master that does 1_24 -> 1_26 | 11:47:49 |
 emily | prophylactic pins are not a great idea absent strong reason IMO | 11:58:37 |
| emily | if we had to bump something because the old version was going EOL and the new one works fine then that's a sign we're failing to keep up and will have less churn if we only pin if something breaks | 11:59:25 |
| Ramses 🇵🇸 | Yeah, but I think that's a question for the maintainers of that package, right? I didn't want to remove a pin behind their back because I'm not familiar with the package | 11:59:29 |
| emily | pinging them is a good idea for sure. but well, if a staging contributor has had to fix it then they get a say too IMO | 12:00:38 |
| emily | in return for the thankless task that I'd triaging these kinds of issues and stepping in for maintainers a lot | 12:01:12 |
| emily | anyway no super strong feelings. I just greatly prefer having only the minimum reactive version pinning | 12:01:52 |
| Ramses 🇵🇸 | I don't disagree. I just wanted to fix the conflict and opted for what I felt was the conservative approach of sticking to what seemed to have been the common practice for this package (I checked quite a bit of the git history to check this). I worried that otherwise I got an annoyed maintainer later on asking why I unpinned their input. | 12:03:02 |
| emily | especially when it's about EOLs. you can have upstreams that stay reasonably in sync with their dependencies' cycles but need manual work for each bump. but less so for supporting only the oldest supported version and still updating in a timely fashion | 12:03:12 |
| Ramses 🇵🇸 | Seems like the kind of situation where you end up annoying someone in any case | 12:03:16 |
| emily | yeah I don't think you did anything wrong :) | 12:03:43 |
| Ramses 🇵🇸 | I fully agree that we should avoid pinning, but a merge commit in -next without a PR to give the maintainers a chance to weigh in, didn't seem like the right place to fix that | 12:05:15 |
| emily | procedurally I err very much in favour of stuff landing on staging, because the workload is high and the contributors are deeply knowledgeable on average and being a time-sensitive maintainer of last resort is no fun if it also lacks the authority to make judgement calls | 12:05:24 |
| emily | but we're violently agreeing I think 😆 | 12:05:46 |
| emily | IMO it was the -next commit that made that call rather than the merge. but those aren't great for visibility for maintainers especially if they're pushed directly, yeah | 12:06:37 |
| emily | (thank you for doing the merge!) | 12:06:45 |
| emily | we really need to move to a PR-only workflow for staging, including for merges. I'll hopefully write up plans for that soon... | 12:07:23 |
| emily | visibility and auditing is pretty awful right now | 12:07:35 |
| Ramses 🇵🇸 | Yeah, but the merge needs to arbitrage between the two (fix on -next, regular bump on master) | 12:07:40 |
| Ramses 🇵🇸 | I noticed a prior issue from you about that, while searching for docs on how to do this merge | 12:08:12 |
| Ramses 🇵🇸 | That would make things a lot more transparent (but potentially also a bit more laborious) | 12:08:39 |
| Ramses 🇵🇸 | I wasn't totally sure whether we were, so good to know! 😁 | 12:09:26 |
| emily | yeah, making the workflow not painful is the main consideration. I think having a pre-made ref you can push to would help offset that | 12:11:29 |
| emily | as well as specifically avoiding mass rebuilds and eval issues percolating to -next which sucks | 12:11:55 |
| emily | I've thought more lately about how we can avoid conflicts arising in the first place though | 12:12:07 |
| emily | the ideal would be that we don't get two PRs that don't know about each other both landing in different "timelines" at all | 12:12:38 |
| emily | multiple merge queues kind of dampen the benefit of having them | 12:13:52 |
| Ramses 🇵🇸 | Yeah, AFAICT, the commit to switch kitty to a non-EOL go could've gone to master, which would've avoided this conflict and discussion. But maybe there were other reasons why it didn't, I don't have the context | 14:20:46 |
| Ramses 🇵🇸 | But in general indeed it's hard to know when you make a PR to master, that there are any conflicting changes on staging(-next). And even if we detected this in CI, I don't think it's always possible to modify the changes such that they cleanly apply on both branches | 14:22:24 |
| emily | well, I had some ideas for making it so that they always can :) but which ones are practical, not sure | 15:52:03 |
