A proposal has been laid out for a new X.Org Server “main” Git branch to house their development going forward and cleaning up the development lapses over the past few years. Ultimately the hope is for having a new cleaned-up X.Org Server and XWayland Git branch for shipping new releases in 2026.
Alan Coopersmith of Oracle laid out the proposal today for a new main branch of the X.Org Server Git repository. The main emphasis is on cleaning up the Git state that became cluttered the past few years when now-XLibre developer Enrico Weigelt was making a lot of changes to the codebase that then ended up with a lot of that code being later reverted. Discussions on IRC determined that it may be easier to start over from an early 2024 snapshot of the X.Org Git state and then work from there in weeding out commits that actually remain present day without being reverted.
Coopersmith explained the situation well in a mailing list post today on the X.Org development list:
“On IRC last year we discussed the mess in the current master branch of the xserver repo, with many reverted commits, and other commits preparing for work which one developer had planned but which will not be coming into our repo now, and some which quite a few other developers disagreed with.
A proposed way forward was to make a new branch called “main” from a starting point around Feb. 2024, and to only cherry-pick over from master the commits which weren’t later reverted and which we generally agreed we’d want to keep.
After doing a bunch of reverts, and then seeing an MR to revert another 40 commits to unbreak the libvnc.so loadable module, I finally sat down to see what this would look like.
…
This main branch has 835 commits since the start point, where the master branch had 1386 (and that’s not counting the 40 reverts from !2102).I’ve eliminated commits that met one or more of these:
– were later reverted, or were the reverts of a commit that was dropped
– fixed or depended on commits that were dropped
– didn’t follow the license requirements to include copyright & permission notices
– caused a lot of churn for little benefit (like mass replacing the PANORAMIX ifdefs with XINERAMA or mass removing HAVE_DIX_CONFIG_H ifdefs)
– broke ABI/API that we know others used
– broke long-standing Xserver abstractions/patterns, like function vector wrapping/dispatchingI did leave some of the “unexport API” commits that I thought might be safe.
I did not merge fix commits into the commits they fix, so there may still be some points in the git history that are unbuildable and not good for git bisects, but there should be fewer than before since the commits we outright reverted are gone now.
I’ve not done any testing on this yet besides building and seeing the CI pipelines all passed, since I’d first like to hear others thoughts on if this is the right direction and the right subset of commits.
Do we want to make a new main branch and make all future release branches from it, abandoning the current master branch? (I hope we can get 26.1 branches of both Xwayland and the other Xservers made this year, after our 25.1 plans for both got scuttled last year by this mess.)
If so, is this the right set of commits to include & exclude? Now is the time to rewrite history on this branch before it becomes official and people start relying on it, if there’s more changes we should drop, or changes I dropped that people think should stay.”
The post in full can be read on xorg-devel. We’ll see what other upstream X.Org developer stakeholders think and ultimately if this will finally lead to X.Org Server 26.1 and XWayland 26.1 releases in the months ahead.
