| 6 Oct 2024 |
 maralorn | Honestly I can see the appeal of not special casing haskell-updates. | 12:36:58 |
 emily | (I just ran into an annoying one that I have to deal with today: someone added a package using OpenJDK 22 on master, which is already EOL. but my PR to do JDK updates, remove OpenJDK 22, and add OpenJDK 23 is waiting on staging. so after master merged back into staging, eval broke, and the person who made the PR has no obvious way to test that 23 will work.) | 12:37:53 |
| emily | (that sort of thing is unavoidable in any kind of branching workflow though) | 12:38:00 |
| maralorn | otoh, I think that hexa switched from staging to python-updates for larger python updates, so their are clearly forces pushing in the other direction. | 12:38:12 |
| maralorn | * otoh, I think that hexa switched from staging to python-updates for larger python updates, so there are clearly forces pushing in the other direction. | 12:38:47 |
| emily | my understanding is that python-updates is for mass batch updates, whereas most Python changes still go to master/staging | 12:39:00 |
| emily | so it's a bit more nuanced. OTOH Python does those batch updates less often than Haskell because they're a pain, I think | 12:39:26 |
| emily | but maybe haskell-updates could continue to be used for Stackage updates and other things are handled on the main branches? not sure. | 12:39:44 |
| maralorn | The difference is, that basically all bumps to Haskell packages are part of a mass batch update. We can probably be a bit less strict about forcing small fixes to got o haskell-updates, but honestly I already am. I have a relatively quick merge finger and do a judgement call on every of those PRs. | 12:42:21 |
| emily | right | 12:43:03 |
| emily | I thought we track Stackage LTS? isn't that more a once every month or two thing? | 12:43:27 |
| maralorn | In reply to @emilazy:matrix.org
I thought we track Stackage LTS? isn't that more a once every month or two thing? Well.
a) Stackage LTS minor releases are about once per week
b) half of our building packages are not pinned in stackage, they are just fetched from hackage and that has updates all around the clock.
| 12:45:54 |
| maralorn | i.e. Stackage only covers a small part of the whole ecosystem. | 12:46:38 |
| maralorn | * i.e. Stackage only covers a small part of the whole ecosystem, roughly 1/6th | 12:47:00 |
| emily | oh right, minor releases | 12:47:34 |
| maralorn | Stackage major releases otoh are more of a once to twice a year thing. | 12:48:19 |
| emily | I'm going to have to deal with this problem at some point soon when I get around to trying to do the Rust crates as separate packages thing, since obviously there all the updates are uncoordinated | 12:48:14 |
| emily | and bumps often require bumps to other crates | 12:48:28 |
| emily | I'd like to avoid a batch process/branch and just send things to master/staging, but we'll see what actually works out… | 12:48:40 |
| maralorn | I feel like I am very often in the "no it can’t be better because XY" position in these discussions. But I am actually very exited for any actual improvement if we can achieve it. | 12:50:12 |
| emily | it's tough :) | 12:52:09 |
| emily | from the inside you know all the reasons why people's preconceptions about the process and what will work are wrong. from the outside, sometimes you can see that the people on the inside are stuck in their own assumptions | 12:52:45 |
| maralorn | In reply to @emilazy:matrix.org
from the inside you know all the reasons why people's preconceptions about the process and what will work are wrong. from the outside, sometimes you can see that the people on the inside are stuck in their own assumptions Exactly | 12:53:06 |
| emily | many a time I have been on the inside saying "nope, you can't do better than that", only to be blindsided when some person I've never heard of before comes along and does better in ways I would have said would never work 😅 | 12:53:32 |
|  @sofo:matrix.org left the room. | 15:27:39 |
| 7 Oct 2024 |
 cdepillabout | In reply to @emilazy:matrix.org
many a time I have been on the inside saying "nope, you can't do better than that", only to be blindsided when some person I've never heard of before comes along and does better in ways I would have said would never work 😅 I totally get this. Just the other day I replied to someone on one of my repos saying it wouldn't be technically possible to fix one of the issues they had opened. Only to realize a few minutes later they had already sent a PR fixing the issue I thought couldn't be fixed 🤕 | 06:00:33 |
| emily | this PR clearly does not exist closes | 06:01:35 |
| 8 Oct 2024 |
 eldritchcookie | how do i unmark broken something https://github.com/typedbyte/apecs-effectful/issues/1 | 14:33:29 |
 MangoIV | Something that just came to mind due to other things: Does anybody who use Nixpkgs + Haskell at work do something crazy like compile the entire dependency tree with certain modifications like specific platform specific instructions or the LLVM backend? | 14:41:22 |
| eldritchcookie | what would be the benefits? i guess if performance is critical you could use SIMD via LLVM but unless you have a custom modification to GHC itself that seems like too much effort | 14:43:24 |
