Draft: [RFC] Xorg-only release branches

The last major X server release has been done more than three years ago on May 2018. Since March 2021 the Xwayland DDX has been released as a separate sub-project with its own release schedule that does not depend on the X server as a whole.

There are new features in the Xorg DDX that I would like to see released, so I'm volunteering to do the releasing work.

XWayland has established a good practice (see !582 (closed)) of cutting single-DDX releases.

The following proposal is basically a copy-paste of Michel's work with replacement of xwayland with xorg-server.

Proposal

• Xorg and Xvfb DDXen are released using the DDX-only release process together.
• New Xorg development continues on the master branch. Everything applicable must land there first, in order to prevent divergent forks of DIX code.
• When there are new Xorg features ready to ship, a new stable xorg-server-<year>.<minor> branch can be forked off from the master branch, and parts of the tree which aren't used by Xorg or Xvfb can be pruned from that branch.
• Bug fixes can be backported from master to xorg-server-x.y the same way as for the existing server-1.y-branch stable branches.
• The initial major release and subsequent minor releases are made from the xorg-server-x.y branch.
• For release cadence, make a .1 release in Q1 of each year, and if there are new features available by Q3, optionally make a .2 release as well. Releases should be aimed to align with regular Q1/Q3 distribution releases.
• One xorg-server-<year>.<minor> branch will be active at any time in general.
• There may be one final x.y.z release from the previous branch after the next x.y.0 release though.

Contents of this MR

Just like !582 (closed), this MR drops all DDXen that are not Xorg or Xvfb and builds Xorg unconditionally. The name of the project is not changed as it's xorg-server already.

Impact for other DDXen

There should be no direct impact, since Xorg-only releases would be made from separate branches, and development continues on the master branch.

If there's a new full xserver major release in the future, Xorg should probably be excluded from it.

Downstream impact

The implementation of this proposal has exactly the same impact to the downstreams as the Xwayland-only releases. Distributions may still decide to ship Xorg and other DDXen from git with all the consequences, or may attempt to integrate Xorg, Xvfb and Xwayland from the DDX-specific xwayland-x.y and xorg-server-x.y stable releases plus other DDXen from the last stable 1.20.x release series.

marked this merge request as draft

I am not entirely sure I understand such a need for Xorg.

The whole point of having Xwayland standalone releases (and branches), as far as I understand, was to get rid of the API/ABI constraints from Xorg and move faster with Xwayland releases induced by the faster moving pace of Wayland and its protocols. I do not see Xorg having such a need.

Also, some servers (e.g. Xephyr, Xnest) have no API/ABI requirements either and would be excluded from such an Xorg-only release scheme.

If anything, I think it should be a all-but-Xwayland release (now that Xwayland has its own branch and release schedule).

But appart from that, what does an Xorg-only branch buys us over stable branches as before?

@ofourdan: Thanks for response.

The primary need is maintainer resources. While I can look after Xorg I can't check all the other servers even for trivial stuff. Doing just Xorg release removes the need for doing even the minimal maintenance work which we probably can't. Even for Xorg it remains to be seen if I will be able to maintain the release, we'll only know once it ships and users don't complain.

If we can declare that everything except Xorg and Xvfb are of "started, seemed to work" quality (or in case of xwin and xquartz - "didn't even try to start") then I'm fine with volunteering for whole X server releases.

You should also be able to easily check Xephyr. From the point of view of a package maintainer for Solaris, the servers we ship and would prefer to have from a unified release are Xorg, Xephyr, Xvfb, & Xdmx (though I'm uncertain if any of our users still use Xdmx, and that would be the most likely for us to drop).

I'm not sure if we've ever expected the server release manager to test Xquartz & Xwin themselves.

@alanc Looks like xdmx has been broken for about 14 years for anything using GL (see this patch which never got merged). The newest activity on any of the bugs referencing xdmx has been 4 years ago. I think it's safe to say that no one is using xdmx.

Sadly, I can believe that Xdmx died long ago without anyone noticing.

mentioned in merge request !637 (merged)

At the moment it's clear that continuing X server minus Xwayland releases is preferred, so the main purpose of this RFC has been achieved. I will not close the MR just yet in case there are more opinions.

The release of X server will still be different than before. We need to remove Xwayland DDX from the X server release because Xwayland is released separately. This means that server-21.1-branch will need to branch off before the RC stage starts instead of waiting for 21.1.0 release to ship.

mentioned in issue #688 (closed)

Feedback has been gathered, seems like we can close this MR.

closed