[prev in list] [next in list] [prev in thread] [next in thread]
List: cairo
Subject: Re: [cairo] Release management for Cairo
From: Petr Kobalíček <kobalicek.petr () gmail ! com>
Date: 2021-04-25 17:47:34
Message-ID: CAB2Z3OekMH1GKO+XCsjktV+3uNcj7OJH8oGBUVpDK_jy73+8DA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@cairographics.org
> https://lists.cairographics.org/mailman/listinfo/cairo
>
[Attachment #5 (text/html)]
<div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>BTW \
It's just an opinion. I'm on this list, but I don't really use Cairo \
anymore, I should unsubscribe \
:)</div><div><br></div><div>Best,</div><div>Petr</div><div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 25, 2021 at 7:12 PM \
Emmanuele Bassi <<a href="mailto:ebassi@gmail.com">ebassi@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi \
all;<br><br>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.<br><br>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.<br><br>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:<br><br> - [libepoxy](<a \
href="https://github.com/anholt/libepoxy" \
target="_blank">https://github.com/anholt/libepoxy</a>)<br> - [gdk-pixbuf](<a \
href="https://gitlab.gnome.org/GNOME/gdk-pixbuf" \
target="_blank">https://gitlab.gnome.org/GNOME/gdk-pixbuf</a>)<br> - [graphene](<a \
href="https://github.com/ebassi/graphene" \
target="_blank">https://github.com/ebassi/graphene</a>)<br><br>I have taken over the \
first two after they stopped being maintained, and worked on getting them to a clean, \
releasable state.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>For this reason, I'd like to \
whittle down the size of the code base. The following backends would need to \
go:<br><br> - OS/2<br> - BeOS<br> - Qt<br> - DRM<br> - GL (GLES, EGL, GLX, \
WGL)<br> - Cogl<br> - DirectFB<br> - XML<br><br>The supported backends would \
be:<br><br> - image<br> - recording<br> - Xlib<br> - XCB<br> - Win32<br> - \
Quartz [1]<br> - Tee [2]<br> - SVG<br> - PDF<br> - PS<br><br>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.<br><br>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.<br><br>Of course, the Meson \
build needs some additional fixes, like:<br><br> - a better test suite integration, \
to enable parallelism and per-backend options<br> - porting some of the existing \
tests currently written as shell scripts, and vetting their usefulness<br><br>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.<br><br>I have started these changes \
in a separate branch, called "Tanis"[3] available on GitLab:<br><br> <a \
href="https://gitlab.freedesktop.org/ebassi/cairo/-/tree/tanis" \
target="_blank">https://gitlab.freedesktop.org/ebassi/cairo/-/tree/tanis</a><br> \
<br>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.<br><br>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.<br><br>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.<br><br>So, I guess my \
question is: would this plan be acceptable to the people still involved with the \
development of Cairo?<br><br>If it is, I'd be happy to work on:<br><br> - \
merging the Tanis branch<br> - cleaning up the documentation, and updating it to the \
current status<br> - refactoring the test suite so that it can properly run on the \
CI pipeline<br> - going through the API reference and ensuring that it's up to \
date and correct<br> - fixing the cairo-www repository, and using GitLab pages for \
publishing the content<br> - doing a new development snapshot<br><br>Ciao,<br> \
Emmanuele.<br><br>[0]: <a \
href="https://lists.freedesktop.org/archives/cairo/2020-November/029080.html" \
target="_blank">https://lists.freedesktop.org/archives/cairo/2020-November/029080.html</a><br>[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.<br>[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.<br>[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".<br \
clear="all"><br>-- <br><div dir="ltr"><a href="https://www.bassi.io" \
target="_blank">https://www.bassi.io</a><br>[@] ebassi [@<a href="http://gmail.com" \
target="_blank">gmail.com</a>]</div></div>
-- <br>
cairo mailing list<br>
<a href="mailto:cairo@cairographics.org" \
target="_blank">cairo@cairographics.org</a><br> <a \
href="https://lists.cairographics.org/mailman/listinfo/cairo" rel="noreferrer" \
target="_blank">https://lists.cairographics.org/mailman/listinfo/cairo</a><br> \
</blockquote></div>
--
cairo mailing list
cairo@cairographics.org
https://lists.cairographics.org/mailman/listinfo/cairo
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic