| 6 Oct 2024 |
 emily | most changes probably aren't cross-cutting in that way but it's annoying when they are :) | 12:33:06 |
 maralorn | In reply to @eldritchcookie:matrix.org
oh makes sense guess i just got salty that my fix took 2 weeks but i never had a contribution that wasn't merged on master rather than staging so I totally get that. To be fair the team of people doing those merges has shrunk by 50% in the last two years. And back then we basically had a pace of one merge per week. We need to get better with onboarding and will put out a call for volunteers shortly. | 12:33:09 |
| emily | I do wonder if master/staging wouldn't be faster overall. staging would be slower, of course, but you can't get faster than merging directly into master when things don't cause a bunch of rebuilds | 12:33:48 |
| maralorn | In reply to @emilazy:matrix.org
and you end up with an experience more like a multirepo Yeah, those are good points. | 12:33:52 |
| emily | In reply to @maralorn:maralorn.de
That’s a bit sad. I promise it is totally fine to just open a PR and we will be very helpful in guiding people in the right direction, which is really not that complicated. And that quickly, easy PRs often get dealt with within a day because we have relatively clear responsibilities. yeah, it is unfortunate, but I also get why people feel that way compared to the language ecosystems that follow the normal Nixpkgs processes more | 12:34:18 |
| emily | though there are of course advantages to batching up updates in a jobset too :) | 12:34:33 |
| maralorn | In reply to @emilazy:matrix.org
I do wonder if master/staging wouldn't be faster overall. staging would be slower, of course, but you can't get faster than merging directly into master when things don't cause a bunch of rebuilds Well then semi-frequently people would do fixes on master which already don’t apply anymore on staging … | 12:35:30 |
| emily | true | 12:36:50 |
| emily | staging people are used to handling merge issues though | 12:36:56 |
| 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 |
