From looking at his Xorg contributions on FDo, his technical work amounts to mostly code style changes and cosmetic-level refactors in an attempt to clean up the codebase. In the course of this, he's broken the master branch on multiple occasions and introduced a large amount of churn in the Xorg ecosystem, all while not fixing any bugs or improving anything user-facing. The reason why he started this fork seems to be that his changes pissed off everyone working on Xorg who could review his MRs, so they started piling up without getting reviewed.
> Changing calls pScreen->DestroyPixmap to dixDestroyPixmap doesn't meaningfully improve the code or make it easier to reason about. Moving byte-swapping of requests and events from one function to another doesn't make the code more robust. Cosmetic changes to the way length fields are written doesn't help with byte vs. word unit confusion, or keep you from writing the wrong amount of data. You're just moving the complexity from point A to point G, not reducing it.
> It is possible to reduce the complexity of the code, by delving deep into the interactions between DIX/MI/FB/DDX to flatten the code flow, making some deep structural changes. Or by using structured (de)marshalling through XCB. Doing this would be incredibly risky, but at least have a much higher payoff than just cosmetic shuffling because it is 'cleaner'.
> The immense value X11 has - that it always had and will have for decades to come - is its backwards compatibility, still being able to run 40-year old apps. You correctly called the codebase 'fragile' - you've been finding this out as your changes repeatedly break things. If you're breaking apps, then what exactly is the value in a codebase which is 'cleaner' to your subjective standard but doesn't actually work?
I think this comment from an Xorg maintainer sums things up (from this issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1797 ):
> Changing calls pScreen->DestroyPixmap to dixDestroyPixmap doesn't meaningfully improve the code or make it easier to reason about. Moving byte-swapping of requests and events from one function to another doesn't make the code more robust. Cosmetic changes to the way length fields are written doesn't help with byte vs. word unit confusion, or keep you from writing the wrong amount of data. You're just moving the complexity from point A to point G, not reducing it.
> It is possible to reduce the complexity of the code, by delving deep into the interactions between DIX/MI/FB/DDX to flatten the code flow, making some deep structural changes. Or by using structured (de)marshalling through XCB. Doing this would be incredibly risky, but at least have a much higher payoff than just cosmetic shuffling because it is 'cleaner'.
> The immense value X11 has - that it always had and will have for decades to come - is its backwards compatibility, still being able to run 40-year old apps. You correctly called the codebase 'fragile' - you've been finding this out as your changes repeatedly break things. If you're breaking apps, then what exactly is the value in a codebase which is 'cleaner' to your subjective standard but doesn't actually work?