Sometimes things do go your way
cross-posted from: https://feddit.de/post/7998742
Meme transcription: 4 panels of Vince McMahon reacting increasingly ecstaticly to:
- Your software isn’t working. Vince McMahon looks curious.
- The bug is in a library. McMahon smiles.
- There already is an issue on Github. McMahon makes an orgiastic face.
- They published a fix last week. [I don’t know how to describe the face McMahon is making.]
649
Comments31
Sometimes the issue is marked as fixed but a new version won't be coming out for months and you're simply told to compile it yourself only to find it has literally hundreds of carefully tuned compilation dependencies and environment specific settings that aren't documented.
What are you trying to build, the equivalent to a death star?
Hello world.
Opensource is the best!! 😅
Open source has no tangible effect on release schedules?
If the software in question was proprietary you wouldn't even have that option. Distro packages could backport that fix too.
Or in my case... The bug has been fixed in a PR that's been open for the last 4 years and the repo owner refuses to merge it.
Fork it. Integrate the PR Branch. Build it... and pray :)
I know that's an option, and others have done just that. I just wish the owner would get the stick out of their ass and merge an obvious improvement.
Maybe they have more important shit to do
But you are 20 versions each with breaking changes behind…
This.
They changed their dependencies and now your stack no longer supports the lib until you fix your whole framework to work with the up-to-date stuff.
The new version isn't backward-compatible and now you've got to re-write your whole project.
Conversely: The new version requires you write it with a different word that makes more sense, so you do an search and replace in a few files and get done with it and nothing breaks.
If you edit code with find/replace, you need a better IDE. Just a hint.
I'm aware, and I do use a good IDE, but I'm simplifying the operation here for the punch line.
I would say finding that the bug is in a library is worse than finding it in your own code.
If it's your own code, you just fix it.
If it's in a library you then have to go and search for issues. If there isn't one, you then go and spend time making one and potentially preparing a minimum reproducible example. Or if you don't do that (or it's just unmaintained) then you have to consider downgrading to a version that doesn't have the bug and potentially losing functionality, or even switching to another library entirely and consequently rewriting all your code that used the old one to work with the new one.
Yeah, I'd take my own bugs over library bugs any day.
Worse is if there is one but it says: [OPEN] Opened 7 years ago Updated 2 days ago, with a whole bunch of people commenting the equivalent of "me too", and various things they tried to solve it, but no solution.
That’s where my ecosystem shines, since it’s all open source. If there’s a bug that I can fix, but the maintainer won’t, I’ll just fork the repo.
The best coincidence I got was "6 hours ago"
I got to leave the "thank you, it worked" confirmation comment
The software is deployed on Ubuntu LTS in prod.
see you in about fifteen years
More like RHEL 5
But you're running Debian, so it'll be 2 years at least before you get it.
Sometimes I feel slightly robbed when this happens. Like damn I was just gearing up for a marathon troubleshooting session and now I just get to use the software as intended?
Lol! Sometimes after configuration/troubleshooting I just log off feeling content, despite never actually starting what I set out to do 🤣
This gave me a boner
The issue was closed as beging fixed but it isn't.
So often...
That overly aggressive issue manager closing tickets because the ticket opener didnt reply fast enough
"Can't replicate, closed."
You mean the patchset was on the mailing list & applying the patch was a simple Nix overlay?
You know, just today I happened to try out getting earlyoom killer notifications on my desktop and wondered why they don't work.