[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