[prev in list] [next in list] [prev in thread] [next in thread]
List: cairo
Subject: Re: [cairo] Release management for Cairo
From: Emmanuele Bassi <ebassi () gmail ! com>
Date: 2021-04-25 18:01:19
Message-ID: CALnHYQHnjjA2ZSaZTquNd=s_dZroiSuxLwPugfLAyoJd_p=QDA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sun, 25 Apr 2021 at 18:48, Petr Kobalíček <kobalicek.petr@gmail.com>
wrote:
> 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.
>
I'd consider this a plus, given that plain Makefiles are usually tragically
less performant. Plus, Meson doesn't *only* target Ninja: it generates
Visual Studio project files, and the Meson maintainer is working on
improving the XCode support.
> Not saying Ninja is bad, but it's an additional dependency and having a
> change accepted in Ninja is also very difficult.
>
Yes, Ninja is an additional dependency; nevertheless, it's available
everywhere.
The point about changes in Ninja is a good one; luckily, there aren't many
changes needed, as far as I know. Additionally, there's a Ninja-compatible
tool called "Samurai", which is ostensibly easier to contribute to.
> 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.
>
CMake is terrible in many, many ways. I have never had a good experience
with it, in my roles as a contributor to projects, as a maintainer, and as
a downstream integrator. Cross-compilation is usually horrific and broken,
and from a maintenance perspective, there's literally no difference to me
between an idiomatic, clean CMake build and a broken one. The Makefile
generator for CMake is busted, and does not really work with parallel make,
to the point that I'd still recommend using Ninja.
> BTW It's just an opinion. I'm on this list, but I don't really use Cairo
> anymore, I should unsubscribe :)
>
Your opinion is nevertheless welcome. Thank you!
Ciao,
Emmanuele.
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
>>
>
--
https://www.bassi.io
[@] ebassi [@gmail.com]
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr">On Sun, 25 Apr 2021 at 18:48, Petr Kobalíček <<a \
href="mailto:kobalicek.petr@gmail.com">kobalicek.petr@gmail.com</a>> wrote:<br></div><div \
class="gmail_quote"><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,<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.</div></div></blockquote><div><br></div><div>I'd consider this a plus, given that \
plain Makefiles are usually tragically less performant. Plus, Meson doesn't *only* target \
Ninja: it generates Visual Studio project files, and the Meson maintainer is working on \
improving the XCode support.<br></div><div> </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"><div> Not saying Ninja is bad, but it's an additional dependency and having a \
change accepted in Ninja is also very \
difficult.</div></div></blockquote><div><br></div><div>Yes, Ninja is an additional dependency; \
nevertheless, it's available everywhere.</div><div><br></div><div>The point about changes \
in Ninja is a good one; luckily, there aren't many changes needed, as far as I know. \
Additionally, there's a Ninja-compatible tool called "Samurai", which is \
ostensibly easier to contribute to.<br></div><div> </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"><div> 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></blockquote><div><br></div><div>CMake is terrible in many, many ways. I have \
never had a good experience with it, in my roles as a contributor to projects, as a maintainer, \
and as a downstream integrator. Cross-compilation is usually horrific and broken, and from a \
maintenance perspective, there's literally no difference to me between an idiomatic, clean \
CMake build and a broken one. The Makefile generator for CMake is busted, and does not really \
work with parallel make, to the point that I'd still recommend using Ninja.<br></div><div> \
</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"><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></blockquote><div><br></div><div>Your opinion is nevertheless welcome. Thank \
you!</div><div><br></div><div>Ciao,</div><div> Emmanuele.</div><br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><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" target="_blank">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> </blockquote></div><br clear="all"><br>-- <br><div dir="ltr" \
class="gmail_signature"><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>
--
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