Uhm ... interesting, looking at the MR description: "Various cleanups in randr codebase, eg. using calloc(), [...]" -- so there it is again! What the ... someone has an obsession with calloc(). I guess he saw crashes caused by uninitialized reads in the past and decided it's best to hide them unconditionally in the first place. If you'd ever do that, you'd hide that behind some build flag only for release builds (to reduce the risk of fallout in production) and do something like "the opposite" in debug builds (fill the memory with some known pattern to help with identifying the
actual bugs).
Then again he was castigated for taking
16 hours to fix a bug in the main branch! As he rightly mentions, the only reason it's such a big deal to break the main branch is
many people are running it because there hasn't been a release in forever. Note that the guy who found and filed the bug is a
big defender of Mr. Weigelt.
Hm, looking at this in isolation, it indeed seems like a stark overreaction. But who knows, the picture might change with context. Regarding master (or main in other projects ... side note, I really don't care what's the default name for the default branch, but I hate the confusion that was created here unnecessarily ...), it's not uncommon these days to have a "always releasable" policy, even if it's regularly broken by accident, even if you have regular releases and ask (most) users to use these ... see e.g. FreeBSD's "src" repository. Obviously, this guy has a different model of that branch in mind, but if you contribute to some project, you should respect their policies.
I really can't make my mind up on this one. I'm going to wait and see.
Well, I made up my mind. I can't claim 100% confidence in my assessment, but it really seems to fit. Of course, first reading these silly MAGA, anti-DEI, anti-"woke" statements in the "fork drama" kind of set the stage, and quickly finding older stories (anti-vax conspiracy bs, "alternative" WW1/WW2 history) completed that. Even if it wasn't such idiotic nonsense, so many political statements in the totally wrong context (OSS development) would always raise an eyebrow.
But then, seeing this ridiculous bug linked here, I still had a look at the actual code, finally looking at several commits leading to that bug. And what I found were changes that were mostly pointless, and if not, not well thought of and "half-assed". Yes, with just 4 or 5 commits I looked at, and this guy probably having created thousands of them, it's not representative. But it's still an astonishing coincidence, cause what I found matches exactly what was stated in various FDO gitlab MRs and issues by other developers who got annoyed.
Just to get that straight, it's fine to introduce new bugs, even in your default branch, occassionally, cause there's simply no way to reliably avoid them (short of not doing any work at all). And then you find them and fix them. The problem here is not introducing new bugs, it's introducing bugs doing changes that don't make much sense (pointless, not adding any value). You're looking at them and just ask .... "Why ...?"