OverviewExploreTrending
Nostr Archives
OverviewExploreTrending
Bill Cypher1d ago
The bugs for sure. The number of bugs in allegedly enterprise production ready software these days is insane. "I know we told you upgrading to 26.03.1a will fix it but now that you did all that work it turns out that wasn't true and also has this additional showstopper bug so you need to immediately upgrade to 26.03.58.xyz" Dude, you were up to 26.03.327.jkl before we started. Why didn't we just go directly to the real fix? "Oh yeah you can't upgrade from what you had to that directly. Any other version you could but there was a bug in the upgrade process that affected those 2 specific versions"
💬 1 replies

Thread context

Root: c72c9827eb6b…

Replying to: a2de2f917eb3…

Replies (1)

ChipTuner1d ago
Yeah I'm not defending that. I think it's another constraint of continuous delivery and cooperative development. The more people work on a project, the less breaking changes can be introduced by design of git branches, they must converge. Now in practice I'm sure this is actually different, I'm making an assumption here. I breaking changes are difficult to cooperate, and maintain a productive cadence among teams, it's frustrating as well. oss guys have even harder times prioritizing contributors too. It means more work for project leads as well, resolving merge conflicts all day. So again I think it's the leaky abstraction from attempting to maintain smooth dev cooperation with a stable release cadence. I can say it's generally not from retardation lol. If a bug was known, but the patch not released, there was likely a cooperative reason imo. That's also to say dev pipelines are pretty deep too. I mean PMs have to schedule merging of PRs, that bugfix likely wouldn't converge in time with the staged PRs so it gets pushed back.
0000 sats