[cairo] Release management for Cairo

Sun Apr 25 17:47:34 UTC 2021

Hi,

I think the proposal makes sense. The only thing I would disagree with is
the Meson build system. It can only generate build files for Ninja, which
means you cannot just use plain old make to build the project. Not saying
Ninja is bad, but it's an additional dependency and having a change
accepted in Ninja is also very difficult. I think CMake would be much
better option in such case - it just provides more options than Meson and
since it has a wider adoption it has much nicer integration with many IDEs.

BTW It's just an opinion. I'm on this list, but I don't really use Cairo
anymore, I should unsubscribe :)

Best,
Petr

On Sun, Apr 25, 2021 at 7:12 PM Emmanuele Bassi <ebassi at gmail.com> wrote:

> 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]
> --
> cairo mailing list
> cairo at cairographics.org
> https://lists.cairographics.org/mailman/listinfo/cairo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo/attachments/20210425/478607e1/attachment-0001.htm>