Skip to content

Draft: [RFC] Xwayland-only release branches

Michel Dänzer requested to merge daenzer/xserver:xwayland-21.1 into master

Premise

There are new Xwayland features that we'd like to ship to users. Since there's currently no clear plan for a new major release of xserver as a whole, I'm volunteering to make releases of Xwayland only instead.

My proposal

  • New Xwayland 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 Xwayland features ready to ship, a new stable xwayland-<year>.<minor> branch can be forked off from the master branch, and parts of the tree which aren't used by Xwayland can be pruned from that branch.
  • Bug fixes can be backported from master to xwayland-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 xwayland-x.y branch.
  • For release cadence, my suggestion would be to make a <year>.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 distro releases.
  • One xwayland-x.y 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.

Purpose of this MR

This MR isn't intended to be merged to the master branch. It's a proof of concept, demonstrating how xwayland-x.y branches described above could start.

Contents of this MR

  • The first commit is from !579 (merged).
  • Drop autotools build system. While this isn't feasible yet for xserver as a whole, it is for Xwayland, so we don't need to deal with autotools on Xwayland-only branches.
  • Drop DDXen other than Xwayland. The only exception is Xvfb, which is needed for some unit tests. However, this MR disables installation of Xvfb, even if it's enabled in the meson configuration.
  • Drop config / exa / miext/shadow sub-trees, which are only used by DDXen dropped from this branch.
  • Build Xwayland unconditionally, change meson project name from xserver to xwayland (so meson/ninja dist generates an xwayland-<version> tarball), and bump the version to 21.0.99.1 (for eventual 21.1.z releases).

Impact for other DDXen

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

However, a similar approach might work for releases of other DDXen as well.

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

Downstream impact

As always, it'll be up to each distribution to choose which release to ship Xwayland from, though obviously we'd recommend using the latest suitable stable release.

For Fedora 34, there's a proposal to package Xwayland separately from other DDXen: https://fedoraproject.org/wiki/Changes/XwaylandStandalone

This could happen regardless of whether there will be upstream Xwayland-only releases per this proposal. Without such releases, Fedora and other downstreams would have to similarly maintain their own branches forked off master instead. Upstream releases per this proposal would save effort for downstreams, and avoid fragmentation between distributions.

Next steps

Xwayland 21.1.0 tentative release schedule:

  • February 3rd: Create xwayland-21.1 branch
  • February 17th: First release candidate
  • March 3rd: Second release candidate
  • March 17th: Final 21.1.0 release

I've created an xwayland-21.1.0 milestone.

This milestone should be set on issues / MRs which need to be addressed or at least considered before the 21.1.0 release.

Edited by Michel Dänzer

Merge request reports

Loading