[cairo] Release management for Cairo

Sun Apr 25 17:12:23 UTC 2021

Hi all;

I have breached this topic on a couple of IRC channels, but I wanted to
open the floor for discussion on the Cairo mailing list, in order to reach
out to the larger Cairo community.

After the last discussion[0] on this list about the state of the
maintenance of Cairo, I decided to have a look at the current development
branch and see what we can do about it.

Background: I am currently working for the GNOME Foundation as a GTK
developer. I have been part of the GNOME community for the past 15+ years,
and maintain a few libraries and low level dependencies of GTK, like:

 - [libepoxy](https://github.com/anholt/libepoxy)
 - [gdk-pixbuf](https://gitlab.gnome.org/GNOME/gdk-pixbuf)
 - [graphene](https://github.com/ebassi/graphene)

I have taken over the first two after they stopped being maintained, and
worked on getting them to a clean, releasable state.

While I have been using Cairo for more than a decade, I have never been
involved in its development. For the past 5 years, the GTK developers have
actually been working on reducing the use of Cairo inside GTK, towards the
use of GL (and Vulkan) as the main drawing API for the toolkit.
Nevertheless, while GTK4 tries very hard *not* to use Cairo in its default
code paths, we do fall back to it whenever GL is not available; on top of
that, we still expose some Cairo types in our API, and we still use Cairo
as the default backend for text rendering and printing. While that might
change in the future, we are still three to four years away from that, and
we'd still have to maintain our extant code and API for a few more years
after that.

>From the perspective of GTK, the current state of maintenance of Cairo is
problematic at best. We'd like to add API and functionality to it, but the
lack of response for those changes makes iterating and fixing issues very
complicated; we are, after all, stretched too thin ourselves. Not knowing
if a change will effectively land, or be part of a release, naturally leads
to workarounds; downstream distributors end up either shipping snapshots of
Cairo, or we end up with issue reports because we have to depend on
unstable features. This inevitably leads to friction between end users,
distributors, and maintainers, and instead of working together we end up
trying to route around one another. This is an untenable situation for
everyone.

Ideally, I'd like to help with the maintenance of Cairo. I am not an expert
in the tesselation code, or in font rendering, or in the image scaling
code; but I can deal with making releases, keeping the CI running,
automating the website maintenance, triaging issues, and fixing the build.
More importantly, since Cairo is still a GTK dependency, I can spend my
work time on those tasks.

Of course, since this might look too good to be true: my offer comes with
strings attached, and this is where things might get controversial.

First of all: Cairo is full of conditionally built code that is barely
maintained, and seldom enabled. This makes maintenance more complicated
because nobody is really exercising the whole code base except for some
long tail end user. Cairo has too many science experiments, and too many
small fiefdoms, and not enough people that care about the whole project.
People end up enabling some random feature without realising that it's a
trap; downstream packagers don't really know what to enable at compile
time, either.

For this reason, I'd like to whittle down the size of the code base. The
following backends would need to go:

 - OS/2
 - BeOS
 - Qt
 - DRM
 - GL (GLES, EGL, GLX, WGL)
 - Cogl
 - DirectFB
 - XML

The supported backends would be:

 - image
 - recording
 - Xlib
 - XCB
 - Win32
 - Quartz [1]
 - Tee [2]
 - SVG
 - PDF
 - PS

This is, essentially, the currently exercised subset of Cairo that GTK
needs in order to work, plus the requirements of other users of Cairo
according to Debian's code search. I'd like to be able to say: "if you want
to keep a backend alive, please show up and maintain it", but the truth is:
none of the backends I'd like to remove are really used by anything that is
currently relevant outside of a moderately long tail of niche users. If you
rely on custom builds for your project/product, I'm sure you can also
continue using Cairo 1.16. I'd be happy to backport all the relevant
changes to the 1.16 branch, before sealing it for good.

Additionally, I would drop the Autotools build from the repository, and
rely entirely on Meson. Maintaining two build systems is not anybody's idea
of "fun", and the extant Autotools build is basically running on cargo
culting alone. Meson has proved itself to be a reliable build environment,
especially after GNOME, Mesa, and the X.org projects have switched to it.

Of course, the Meson build needs some additional fixes, like:

 - a better test suite integration, to enable parallelism and per-backend
options
 - porting some of the existing tests currently written as shell scripts,
and vetting their usefulness

With the Autotools build gone, it's possible to avoid targeting the minimum
common denominator, and ensure that Cairo can build properly on multiple
platforms. GTK currently builds Cairo as a Meson sub-project on Windows
(with the MSVC toolchain) and macOS, which gives us a functional baseline.

I have started these changes in a separate branch, called "Tanis"[3]
available on GitLab:

  https://gitlab.freedesktop.org/ebassi/cairo/-/tree/tanis

Some of the commits there are fairly uncontroversial, and deal with fixing
compiler warnings or other small build issues. The commits prefixed with
"tanis" are the ones that I feel are going to be more controversial.

As I said above, I am not really involved with the development of Cairo; I
am just a downstream consumer of it. The larger Cairo community might not
be enthused by somebody dropping by and asking to assume the role of
release manager with a laundry list of changes that drop code and features.
I *do* empathise with that, and I'm entirely prepared to a "get lost" reply.

Sadly, it seems that the other option is keeping Cairo on life support,
landing changes but never really releasing them; since there are still
downstream users of Cairo, and those projects do have quite some traction
in the larger free and open source ecosystem, either those projects will
accelerate dropping Cairo, or will be forced to perform a soft fork, with
an ABI compatible release from a separate branch or repository. Neither of
those solutions would be acceptable to me, and I'm sure multiple
downstreams would also find it very hard to swallow.

So, I guess my question is: would this plan be acceptable to the people
still involved with the development of Cairo?

If it is, I'd be happy to work on:

 - merging the Tanis branch
 - cleaning up the documentation, and updating it to the current status
 - refactoring the test suite so that it can properly run on the CI pipeline
 - going through the API reference and ensuring that it's up to date and
correct
 - fixing the cairo-www repository, and using GitLab pages for publishing
the content
 - doing a new development snapshot

Ciao,
 Emmanuele.

[0]: https://lists.freedesktop.org/archives/cairo/2020-November/029080.html
[1]: Provisionally; the performance of the Quartz backend on modern macOS
has degraded to such a point that it's literally faster to draw on image
surfaces.
[2]: I have checked on the Debian code search, and while the Tee backend is
still in use for Firefox, I'd also consider dropping it given its
experimental nature.
[3]: an old capital of the ancient kingdom of Egypt; and, of course, the
fictional resting place of the Ark of the Covenant in "Raiders of the Lost
Ark".

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo/attachments/20210425/ce30c011/attachment.htm>