Not sure what Linux Desktop to use? Use this handy guide:

- GNOME: when you want no tray icons, themes that break every minor GTK release, and extensions for basic features (that are buggy.)
- KDE: pretty go-Segmentation Fault
- DWM/Awesome/i3/etc.: when you feel like the time you spent learning Vim wasn't wasteful enough
- XFCE: when you want one update per decade and poor Systemd support.
- LXQt: the biggest positive is that it doesn't use GTK.
- Cinnamon: when you like GNOME 3 but you want a different menu
- Deepin: when you want a desktop with the build quality of an HP laptop.

Aren't sure whether to use Xorg or Wayland?

- Xorg: if you want to absurdly fuck up your touchscreen, pick this one.
- Wayland: if you want to screw up most of your apps, too bad; this won't work with your proprietary drivers. If only it did.

What distro to use?

- Ubuntu: if you want to break your system with PPAs, check out this one.
- Debian: when you want Ubuntu except with more out of date packages
- Redhat: when you want Debian except with more out of date packages
- ElementaryOS: wait, someone actually made a properly designed Linux UI?
- Arch Linux: the only thing that doesn't make me sick anymore.
- Slackware: "that exists still really?"
- Gentoo: when you hate systemd more than waiting 4 days to compile Firefox on every release.

... I love Linux. I do. But it is very taxing to get things comfortable for me anymore. I feel like the Linux Desktop is in a period of flux and it's painful to be a part of right now.

Don't you love it when there is a new minor release or a critical dependency and it breaks backwards compatibility without mentioning any of it in the changelog or docs?
I absolutely love it! ❤️❤️❤️❤️❤️
I certainly did not waste 3 hours of my life to find it. No i didn't.

Get assigned ticket.
Finish the most of the feature. Finish most of the specs.
Push.

Second dev wants to own accounting half of the ticket.
Rip out half my changes, rewrite specs.
Push.

Code review asks for minor changes.
Finish them.
Push.

Product creep creeps the scope.
Finish the feature again.
Push.

Product creep creep-creeps the scope.
Finish the feature again.
Push.

New release happens.
Merge in master; fix conflicts. Run specs; random unrelated specs fail, some fail intermittently. Rabbit holes of complicated, unexplored, obviously-flawed code.
Fuck that. Push.

Me passing time on the weekend

Random call from unknown number

Turns out it's the manager

M: hey , how is your weekend going ...

Me: nothing much ... Whatsup ?

M : yeah well , we wanted to push some minor adhoc fixes as some clients wanted it urgently

The Devops folks need developer support . Can you pitch in and monitor

Me : I'm not aware of what changes are going , i don't think i can provide support

M : don't worry it's minor changes , it's already tested in pre prod , you just need to be on call for 30 mins

Me : ugh okay .. guess 1 hr won't hurt

M: thanks 👍🏽

Me: *logs in

*Notices the last merged PR
+ 400 lines , implemented by junior dev and merged by manager

*Wait , how is this a *minor* release...

*Release got triggered already and the CI CD pipeline is in progress

*5 mins later

*Pipeline fails , devops sends email - test coverage below 50%

Manager immediately pitches in ...

M: hey , i see test coverage is down , can you increase it ?

Me: and how do u suppose I do that ?

M : well it's simple just write UTC for the missing lines ... Will it take time ?

Me : * ah shit here we go again

Yeah it will take time , there are around 400 lines , I am not aware of this component all together

Can you ask junior dev to pitch in and write the UTC for this

*Actually junior dev is out on a vacation with his girlfriend

M : well he's out for the weekend , but
as a senior dev , i expect you to have holistic understanding of the codebase and not give excuses ,
this is a priority fix which client are demanding we need this released ASAP

Me : * wait wat ?

---

I ended up being online for next 3 hours figuring out the code change and bumping up the UTC 🤦🏾

After 8 iTunes Testflight Beta approvals for my app ... better still, I got hte app approved for the App Store a week ago to "de-risk" our "final submission" ... That's 9 approvals for my app, and we're ready to submit version 1.0.0 and actually release on the store. We take last week approved app and "developer reject" if to make room for the final tweaked version (minor tweaks, minor bugfixes). Submit version 1.0.0., plenty of time before it needs to be released.

But, what's this? "Meta Data rejected" for v1.0.0 because some piece of shit at Apple wants to watch a video of the app working with our hardware. What about the previous 9 approvals with the demo account connected to the demo hardware?

So we send a video within 1 hour of their unexpected request about the very foundational fucntionality of our app. That was 24 hours ago and these fucking assholes haven't even responded, no sign of when they will trouble themselves to respond. Pure limbo.

All the work up to this point was to "de-risk" their infamously shitty review process and all of it was in vain because it's somehow brand new information that our app works with our hardware.

Holy fuck, what a bunch of power-tripping assholes. All I can do is pace around and review the previous 2 months in my head to figure out what I could have done better. But I could not possibly have expected that after all the Testflight Beta approvals and after the recent App Store approval, that they would suddenly doubt that our software actually works with our hardware!!!!!

FUCK YOU APPLE!!!! FUCK YOU WITH ALL MY HEART!!!!!!

Hey Root, remember that super high-priority ticket that we ignored for five months before demanding you rewrite it a specific way in one day?

Yeah, the new approach we made you use broke the expected usecases, and now the page is completely useless to the support team and they're freaking out. Drop everything you're doing and go fix it! Code-complete for this release is tonight! -- This right after "impacting our business flow" while being collapsed on the fucking floor.

Jesus FUCKING christ, what the fuck is wrong with these people?

If I dropped the ball on a high-priority ticket for two weeks, I'd get fired, let alone for five fucking months.

If I was a manager and demanded a one-day rewrite I can only imagine the amount of chewing out I'd receive, especially on something high-priority.

And let's not forget product ownership: imagine if I screwed up feature planning for someone so badly I made them break a support tool in production. I'd never hear the end of it.

Fucking double standards.

And while I'm at it. Some of the code I've seen in this codebase is awful. Uncommented spaghetti, or an unreadable mess with single-letter variables, super-tightly coupled modules so updates are nearly impossible, typos in freaking constants added across sixty+ files, obviously-incorrect comments, ... . I'll have to start posting snippets to show them off. But could I get away with any of it? ha. Hell no. My code must be absolutely perfect. I hear about any and every flaw, doesn't matter how minor, and nothing can go out until everything is just so.

Hell, I even hear about flaws in other peoples' code during my code reviews. Why? Because I should have fixed it, that's why. But if I do, I get yelled at for "muddying the waters."

Just. JESUS FUCKING CHRIST.

It's like playing a shell game where no matter which shell I pick (or point to their goddamn sleeve where they're clearly hiding it), I get insulted for being so consistently useless, and god damn, how can I never find the fucking pea or follow the damned rules? I'm so terrible and this is why "nobody trusts me." Fuck you.

I'll tell you why I can't find your damned pea: IT'S RATTLING INSIDE YOUR FUCKING HEADS, you ASSHOLE FUCKING IMBECILES.

That's right: one pea among the lot of them.

goddamn I am fucking pissed off.

There is this minor problem that won't affect any user in thousand years...

But then a developer notices it one day before release

Excerpts from "Bastard devops from hell" checklist:

- Insistently pronounce git with a soft "G" and refuse to understand people not using that pronunciation, the same goes for jithub, jitlab, jit lfs, jitkraken etc.

- Reject all pull requests not in haiku format, suggest the author needs to be more culturally open minded when offending.

- increment version numbers ONLY based on percentage code changed: Less than 1% patch increment, less than 5% minor increment, more than that major version increment.

- Cycle ALL access keys, personal tokens, connection strings etc. every month "for security reasons"

- invent and only allow usage of your own CI/CD language, for maximum reuse of course. Resist any changes to it after first draft release

I am calling this a premonition rant, of more rants to come.
I have a feeling in my bones.
We have a newly acquired fat cat customer with bucks to blow who we have done some digital work for already and swag bag of marketing perkiness.
I will call the CEO of this whale "The Porcupine"
The Porcupine has a business degree and industry experience, nothing to do with websites or applications.
It claims to be a visual perfectionist yet never delivers an overall coherent review.
It likes to fixate on minor brand style differences in websites and apps we have built.
The Porcupine seems to be always busy with policy and legal and other things rather than participating in their own projects.
Procrastination on feedback or reviews until the day before release is common.
Many overtime hours worked, not a sliver of thanks. The haughty attitude indicative of somebody who thinks web development is like desktop publishing.

"It's just code" in response to a crash production server change they were warned was a risk that borked all of our responsive templates and took 3 hours to fix.
Their entire brand is shades of pea green, grey and lime. No serif fonts because they are suck. Arial and Helvetica are boss.
One of my devs missed a CSS style on privacy policy hyperlink text that went times new roman and I had various account directors and our CEO on phone telling me how embarrassing it was for us to let this happen.
Anyway. They pay on time and the cost estimates for all the upcoming work are juicy.
We have shitloads going on for an upcoming hard date conference and everything is already compressing.
Therefore I can already smell doom and feel those porcupine quill getting closer to my ass as I beg their AD today if we have any feedback on the 10 or so project reviews yet?
Nope.

What was wrong with the major updates and clean modern UI? It was the only reason that made us happy.
Now buggy and not surprising minor updates, doesn't really support touch like 8.1, poor animations, poor etc. that looks like a quick without-love development to just "release quickly".

Anyways, who else liked the modern metro UI in 8.1 and sad about going back to traditional desktop on win10?

When someone asks you to test something before pushing a release...releases anyway and tells you any fixes can just go in the next minor release 😫

Any individual project that made me learn cool stuff...

Maybe the kernelcheck project? It's a shell script that I wrote 2 years ago (it's still on my GitHub but the code looks kinda horrible tbh), and it really made me respect the stability of package managers, and the effort that package maintainers must put into it. Even a single package (the kernel) that you have to maintain the integrity of the .config for (the configuration file that tells you what options to compile in, as a module, or not at all) while on every new minor release, the config changes ever so slightly.. at some point I figured that I'd really need to do those compilations manually, to be able to supervise (and if necessary adjust) it in real-time. The ability for distribution maintainers to do this for thousands of packages.. it boggles my mind. Respect!

So in the project I’m working on we were about to do a push to live, no major functionality just minor adjustments and nice to have stuff. One of the things I did was a reminder, nothing special just sends an email out if something hasn’t been done for 3 days and then sends an email every day following. Push to live and every thing goes fine with no issues. Day 1 there are no issues. Day 2 there are no issues. Day 3 and I’m inundated with people telling me that the emails are getting sent to practically everyone, shit. What have I done? What have I missed?
So I start looking at the live database hoping for a data problem, no such luck. I look at my code looking for something blatantly obvious but nothing. I start replicating the data but I can’t reproduce this bug and it’s annoying the hell out of me. I checked one of the emails that the client sent to us more thoroughly and seen that it was sent at 07:01. This is odd as our webjob runs at 1am so I start looking at environmental factors and started looking at release management, more out of hope than expectation. I check the staging environment and see that the webjob ran at 7:00. Coincidence I thought, the webjob gets packaged on the release pipeline and everything in the database was dummy data anyway but I’d better check anyway. The database was an exact copy of the live database, turns out a “senior developer” wanted to sanity check everything by running live data through the code so he copied the database over. It was fine for the first couple of days but the data was now 3 days out of date triggering my email code and I get hit with the shit storm. I’ve never met such an incompetent developer in my fucking life, functions 700 lines long, classes that are over 20000 lines, repetition every where and the only design patterns he’s used is when he picks up a child’s colouring book. I can live with the fact that he writes code like someone on their first day of University But copying a database because he wants to “visualise” the fucking data is absolutely farcical. No wonder the project is fucked with a “developer” (in the loosest possible use of the word) is at the helm.

Man I am tired of my company's dogshit software release process.

We have to commit to fucking estimates for 6 months (2 quarters), SQA shadowing dev by 2 weeks, and freaking estimates and work done at the end are not even close. And then we call it a minor release. These shitty estimates are based on requirements that basically say "we want feature x, plz make it work". It's some fucked up agilefall garbage that does not work for shit.

We rush like motherfuckers during the final weeks because estimates are bullshit but we are still expected to be done with every story points which somehow are days instead of other better metrics.

I swear this fucking bullshit has been designed by the board so they could plan their money entries based on the software release.

The only reason this company actually still holds itself up is because the engineers are good at their job.

Go fuck yourself high management.

Why they are keep assigning tasks (new features as minor fix) till release date. And want me to complete it a week before release date.
HOW?

Python async is a total, unapologetic shitshow. It’s as if the design goal was explicitly to invalidate the maximum number of thoughtful stackoverflow QAs possible. Pro tip: make you sure to memorize the release dates of every minor version of python from 3.5-3.10, so that you know which stackoverflow answers are not relevant in any way to your codebase.

Oracle, what's wrong with you? Why do you have in every minor release of glashfish after 4.1 weird bugs which cost several hours of debugging of the own software until discovering there's a glassfish bug occurring in typical situations but there is no fix in sight.
In 4.1.1 there was a bug in the admin panel which throws a exception if you tried to configure JMS and in 4.1.2 there is a bug which prevent finding and loading a necessary class for using jax-rs despite it's available.
I have do complete an assignemt until friday and such bugs are such a pain since i change so many thing just to find out that my first structure/config/etc. was correct.

Fried two devices today by simply connecting them to a power source.

Changed nothing in the circuitry, no shorts due to solder residues (a simple modification was made), no changes in the input parameters. Check.

The afromentioned devices should have only minor HW changes compared to a previous version I'm working with and as far as I can see absolutely nothing which should cause the damn microcontroller to release smoke like a steam train. (All right, a very miniature steam train.)

So the only significant difference might be the firmware which I didn't check yet but will tomorrow. Not my code and the corresponding IDE just basically sucks. Yay.

On the other hand, the Software part finally feels like I'm getting somewhere. It seems just ... to work. Very suspicious.

Feeling ambivalently frustrated and relieved at the same time. Sigh.

Discords update "policy" is really annoying.

I daily-drive Manjaro and discord refuses to allow you to log in with an older client version when they release an update.

Manjaro's stable takes about two weeks to catch up so when this happens I'm stuck looking for an alternative way to update.

Usually I go for the AUR or (if available) unstable branch package but today the AUR wasn't up-to-date yet when I encountered this problem.

This is a minor inconvenience and was fixed about an hour later when the AUR was updated with the newer discord-electron-bin but I just don't get discords game here?

Why not allow the previous client version to connect and alert users of an available update like any other sane chat application does?

You could go for a time period like two weeks or a month and AFTER that start forcing users to update. I don't get why they force it the instant they release the update.

Just wanted to share this annoyance here, maybe someone encounters this possibility when designing update cycles for their application. I urge you not to instantly lock-out older versions. It's annoying, useless and restrictive. Or if you do so, opensource it so repositories can immediately build from source and sync and don't need to wait for a maintainer to update the bin in the repo.

Staged a minor patch to auto release tonight, just before christmass. Wish me luck.

Is it me or software subscriptions make developers lazy?

There is a great photo editing software: Capture One. Every year they release a new major version, so users need to buy an upgrade. In the past developers packed a bunch of big changes into major update, also they released 3 minor updates yearly, and every minor update brought some cool features. But then they added subscription model which was cheaper then perpetual model. And at the same time major updates became not that cool. Developers started to add enterprise features needed by museums, features involving other camera brands users, changes targeted at newbies and so on. For perpetual model users most of these changes are not worth 80-255 EUR yearly (depends on license type and offs) but is ok for subscription model users because they continue using the software and even small updates and enhancements are fine for them.

Not every major update is that weak but many of them are not worth upgrade. And developers are not motivated to do more cool stuff because subscription model users will continue paying for their subscriptions.

To the reactjs-centered fucks who develop the popular web component viewing software called storybook: have you ever heard about semver?
89 alpha/beta/rc releases for a minor update 6.3 -> 6.4 with "100's of fixes and enhancements" "in preparation of the HUGE 7.0 release". Gee I wonder will it have 1000's of bugfixes? How bug-ridden is this software?
Every minor upgrade since 5.x is backwards-incompatible and requires a day of frustration finding out in how many more fucking NPM packages you split your codebase just because it's cool. I know move fast and break things, but some of us have other things to do than resolving node_modules incompatibilities you know. "No just hit 'npx sb upgrade' you say". I did, I really did! And the browser showed a blank screen of death with tons of cryptic React errors, it really did! Thank God you abstracted away all your dependencies in that sb command, now you can't even read the docs about what could have gone wrong with a specific sub-package. You have @storybook/html but the docs redirect to React pages, so good luck if you use something else

This is so sad... like.. the IDEA of storybook is great. But why did faith put the capacity to develop such a tool into the hands of people who think the world centers around React and JSX.. HTML should have been the default, and then you build on top of that for your fav framework, not the other way around

My manager asks, in Slack, if we can change the auto-tagger to update the patch instead of the minor version. I respond by saying, "Yes, it's in the Jenkisfile. Really we should switch to just <major.minor> and drop patch."

My manager asks why and I go on to say the last number is useless (unless you ship software externally and need to hotfix or security patch a minor release; internally they serve little purpose).

At my last job we dropped three numbers for two, and most other teams here only use two numbers.

He sends a link to the semantic versioning website.

The next day one of the other developers sends it to me in a private chat as a joke. 😂😅 I'm glad I'm not the only one who thinks our manager shouldn't be a manager.

"Here is a minor update to our library from 0.8.x to 0.9.0. - Oh, and it is breaking everything, because we changed the API."

o'rly?!

What on earth will happen on a major update?

Really, what is it with the fear of major release numbers? Just name it 1.0 and 2.0 if you break 1.0.

Better yet: just give it a new name. Thingy2 would totally do the job.

Extremely frustrated with the release process and versioning system at my current company. Don't know if this is same everywhere or the half ass release managers can't think of a better way here.

Basically for any client raised issue that can't wait for next release are built as a hotfix. However hotfixes are never bundled togather or shiped to other clients. This is causing a vicious chain, two clients raise two separate issues on same version. Instead of fixing them as single hotfix (however minor the issues) we create two hotfix versions for each with only their issue. A week later same clients come back with the issue the other raised. Once again instead of bundling what is now effectively same code we build hotfixes on top of the clients respective branches. We now have two branches to maintain with same codebase. No matter how serious issue, the hotfix is never made generally available and always created on client's specific hotfix version.

Now that was an example for only two clients, in reality we have released five patch versions of a product in last 2 years. Each product version contains about a dozen artifacts (webapps, thick clients, etc) with its own version. Each product version being shipped to various clients. Clients being big banks never take a patch of product even if it fixes their issues and continues requesting hotfix. We continue building hotfixes on client branch and creat ever increasing tech debt. There is never a chance to clean up or new development. Just keep doing hotfix after hotfix of same things.

To top if all off, old branches are still in svn while new in git. Old branches still compile with ant new with maven. Old still build with java 5,6,7 while current with 8. Old still build from old jenkins serve pipelines while new has different build server. Old branches had hardcoded integration db details which no longer exists so if tou forget to change before releasing it doesn't work.

Please tell me this is not normal and that there are better ways to do this? Apologies I think I rambled on for too long 😅

There was a project I took over that was supposed to be at 90% when the previous developer quit. The project was in QA with some "minor" bugs that needed to be fixed. When I looked at the minor bugs I realized that the project had major underlying data issues. So after working 80 hour weeks I managed to hobble it together and make the release date.

That was a little over three years ago. Since then another developer has taken over maintenance and enhancements on the product and overall the application works pretty well for what it is.

So his analogy is, that the application is a tank that was made out of aluminum foil that has been hit many times in battle. Whenever it has been hit we have patched the tank with random things like bricks, soda bottles, and old car doors yet somehow it keeps going. The tank is still surviving the war but we really don't know how.

🐜

#Suphle Rant 11: Laravel board launch

The launch took almost 2 weeks more than originally slated, because I sought to install it manually, just as an outsider would. Installation steps had been documented, automated tests for the installation tests were passing. When time came to actually execute the binary from the terminal, we went from one obstacle to the other. First, were the relatively minor Composer/Roadrunner issues, eventually resolved by the helpful RR maintainers who sat with me through a Discord server for about 2 hours until their command ran the way I needed it to.

Next was the Psalm scare: One of my value propositions was the guarantee of eliminating all type related bugs in Suphle apps. I intended to use Psalm for that. Wrote tests as usual. Turns out the library behaves differently under conditions differing from raw CLI usage. I resurrected threads I'd opened since December that were left unattended, and with some help from the maintainer, we eventually got it to do what I need it to do.

I was all the more frightened by the fact that Transphporm had caused me to renege on one of my earlier promises. I can only miss so many targets. After this, the docs had to be updated with all the changes effected to accurately integrate those two. Project installation and initialization commands were ran rigorously to ensure all progresses smoothly.

Tagged one final release and suddenly became impatient to launch on our local Laravel group chat where I've been a member for the last 4+ years, where we've had a rollercoaster of emotions. In that time, I've refined my launch speech to suit that audience -- obviously, countless times. Not just a tame "It's my pleasure to announce what I've been working on", but near 40 messages going into details about the inner workings, why it was built, how it compares. An expose that dove deeper than I would anywhere else.

I scheduled a time for them to tune in and got some encouraging anticipation. Ended up deflated after posting the whole thing. Only about 5 persons interacted. 1 (who I've chatted with outside the board) was quite enthusiastic. Feverishly checked the docs but commented it was overwhelming and he'd need more time. Already starred the repository.

For some context, there are give or take 250 members on that board. Not all are active but activity there easily reaches a crescendo when the topic discussed is about inanities like what 3rd party services to use for SMS, how to receive salaries from abroad, or job openings. I was optimistic when the acquaintance mentioned above published a payment library and met a riotuous welcome as one of their own. Maybe, they are simply not fond of me and the speech should have been passed off to someone else.

I checked Packagist installs -- not more 10. For 3 years, I'd been hyped up for that night; but for some reason, the audience I considered myself closest to flopped, woefully. Thankfully, this isn't the main launch. I'm still holding out hope for that. If it fails, I would have sunk an immeasurable amount of effort and time, that nobody will compensate me for. That is the one place I go to see those more advanced than me in PHP. I constantly learn there and find stimulating conversations there.

Now, I can no longer predict reception from other presentations. All I can do now is hope

When it comes to dev tools, It seems like everywhere you turn these days all you get is a rabbit hole trip to GitHub's issue queue WTF! Oh, and there are so many tools out there so we all now need to have a task management tool which just add to the complexity of local dev development, fuck that! To make matters more absurd, those who write them tools think that it is a great idea to rename commands between each minor release because why not after all machines know how to decipher changes right? Wrong, last I checked, machines rank high on the autism spectrum and won't find a command unless you lead them directly to its file system location. The command fuck you could not be found are you sure you spelled it correctly, or did you mean fuck me? is all that it's capable of. Sigh...

Finally release the next version of my own asocial (*) medium, wegurus, which will feature SEO friendly urls, responsive layout, and a lot of minor and major fixes under the bonnett.

(* Asocial because it's basically just me and my mum using it atm ;))

So who at Xilinx decided that their toolchain should only support a years old Ubuntu version which is buggy and one minor release behind LTS?

Running tests on Codeception. Upgraded 2.4.0 to 2.4.1 and 40 out of 280 tests fail. Apparently Yii2 module has been "refactored". Fine, upgrade to 2.4.2 that fixes the issues reported in 2.4.1 - another set of tests fail for different reasons. Digging deeper. Turns out the "refactoring" includes a very opinionated change of behaviour when components have some internal state. But if it's acceptable to pass testing framework module rewrite in a minor bugfix release - then fuck Codeception in general.

OpenSource is fun they said. I being a bored teen thought, ah, another chance to experiment. Discover something new. Now I am into piracy, movies, music, software. If I can get it for free I ain't paying for it. So I went on to GitHub to see what exciting new Repos I could contribute to. I hate already implemented plenty of algorithms in GO for GitHub.com/TheAlgorithms so I was looking something more practical, more beneficial to society. Then I saw it, the perfect repo, not too complex and not amateur. SpotDL/spotify-downloader for downloading songs from Spotify, a grey area coz it's technically piracy. Well not from Spotify, we fetch the info from the Spotify API and search for the songs on YouTubeMusic. They were just about to release v3, a complete rewrite of the codebase stressing code readability and stuff. I spend about a day studying the codebase, trying to findout just where I could make my contribution. I can see outright that there's a huge problem with implementation.

First of all the script spawns 4 processes for downloading songs though you might be downloading only one song. Which means for everytime you run the script you have to wait for 4 other processes to be spawned before any downloading can happen. Sure this is faster when you are downloading more than like 4 songs, but it's actually slower when downloading a single song. But I ignored that coz I assumed that most users download playlists and albums. Anyway we talked with the like lead developer and he was all like, make those PRs anytime you feel like. So I made a really minor first contribution.

I introduced download from Spotify URI functionality, modified like 10 lines of code. I was half expecting that the PR would be merged within hours at most 24 hours coz of how minor of a contribution it was, 5 days in it was pending. So I tagged the lead Dev and he was all appreciative of the PR, calling it real 'clean code' and stuff. 3 more days, the PR is still not merged. I have now stacked 4 more commits to the same PR, I tag the dev and he's like he's waiting to see if my 'feature' will get atleast 10 upvotes so that it can be merged, he links an issue. I go to the issue and my feature is not there, So 11 days after I made my PR I have to write a comment explaining the 'feature' introduced in my PR and then wait for 10 upvotes.

I was like f**k this, I'll just develop on my fork if you want the features on my fork, you will make your own PR! I am so done with OpenSource, development is slow. I have no idea how you guys do it. I can't handle development where I don't have write access.

Fellow Ansible developers. I'm talking to you.
Are you freaking high or simply your morning pills have some serious side effects?
How do you manage to introduce a number of regressions in every fucking major release? How on earth you feel comfortable in breaking API in a minor and even bug fix releases?
You need to get me right. I really like Ansible project but those things... I imaging you every other day as a bunch of hamsters trying to find an exit in a shitty labyrinth which you call the codebase.
If you will not stop to eat and smoke those things this would became a lot worse indeed.

How many of you prefer monkey patching vs minor release??