<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello!</p>
<blockquote type="cite"
cite="mid:CALnHYQFGEJJMvMO9nkpMk0ZiDHGSgr=aKPBP8_O=atfCioW21g@mail.gmail.com">
<div dir="ltr">From the perspective of GTK, the current state of
maintenance of Cairo is problematic at best. </div>
</blockquote>
Truth be told.<br>
<blockquote type="cite"
cite="mid:CALnHYQFGEJJMvMO9nkpMk0ZiDHGSgr=aKPBP8_O=atfCioW21g@mail.gmail.com">
<div dir="ltr">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>
</div>
</blockquote>
<p>I am not sure what changes you mean and haven't seen any
discussion not MRs for them, but I will try to make some general
points. cairo is a relatively old software project. You can see
already where things that did not really fit into the design were
added. This makes adding new APIs problematic. Of course it comes
down to the concrete matter of things you want to add, but in
general my advice, whenever it is possible to layer some feature
on top of cairo, would be to do so. There are things that cannot
be done "from the outside", though, and for these things chances
are you will find an open ear to listen to ideas.</p>
<blockquote type="cite"
cite="mid:CALnHYQFGEJJMvMO9nkpMk0ZiDHGSgr=aKPBP8_O=atfCioW21g@mail.gmail.com">
<div dir="ltr"><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>
</div>
</blockquote>
As cairo is seriously lacking development resources, you then should
have a look at the unstable features you mentioned and see what you
can do to fix the problem. I think most issues can be fixed without
expert knowledge but only require someone to dig into the code - if
the features are already implemented, that is. If you stumble about
something that does need special insight, well.... good luck. Most
of the code is orphaned.<br>
<blockquote type="cite"
cite="mid:CALnHYQFGEJJMvMO9nkpMk0ZiDHGSgr=aKPBP8_O=atfCioW21g@mail.gmail.com">
<div dir="ltr"><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>
</div>
</blockquote>
<p>As a description of a symptom this might be true, of course. But
the easy advice would be to not enable any feature that you don't
miss.</p>
<p>I am not quite sure what you mean by the care for the whole
project versus "fiefdoms". Different parts of cairo were written
by different people who seem to have lost interest in the course
of time. This, of course, is perfectly fine, but now it can be
felt that major parts of cairo are lacking experts. You will
definitely not find the monarch of backend X who closely watches
everything that happens in his domain and strives to realize his
greater plan - unfortunately.</p>
<blockquote type="cite"
cite="mid:CALnHYQFGEJJMvMO9nkpMk0ZiDHGSgr=aKPBP8_O=atfCioW21g@mail.gmail.com">
<div dir="ltr"><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>
</div>
</blockquote>
<p>In the eyes of the lack of dev-resources this might seem good and
well. But how do you come to this distinction? From my point of
view the "supported backends" are just as abandoned as is the
rest. For example, there is no actve developer with a deeper
understanding of PDF, or PS. The quartz-backend sometimes gets
fixed by mac-users that stumble upon bugs (thanks for that!), but
has open issues that nobody can really work on.</p>
<p>My stance on this issue would be more like: If there are no
concrete complaints, things seem to work just fine. And if there
are complaint: This is open-source. Fix your problem!</p>
<p>It's not that I would find the proposal indiscussable ( I have no
real interest in those backends - why not drop PS, Xlib, Win32 and
Tee as well? ), but I do not see a strong reason to do so. Most of
the removal-candidates on your list are listed as
experimantal/incomplete. That's it: if someone has interest in
working on those, they are welcome. Lack of active development,
however, cannot be criterion for removal: You would have to throw
away far more than those...</p>
<p>The reason you give (easier development) is abstract in the light
of concrete circumstances. If, for example, a feature would need
to be implemented in (some) backends, you definately will have to
implement it in the image backend. If you have done that you
already have implemented the default-fallback for backends lacking
a specialized implementation. Such a fallback isn't performant,
pretty or elegant but could be improved later - if there is
someone interested in doing so, that is.</p>
<p>You would have to come up with concrete proposals, but in my eyes
cairo is more or less "finished". No new features, no new
responsibilities. Improving what is there by fixing bugs is the
top priority. cairo has a pretty narrow scope (vector graphics),
which makes it a viable choice if that is exactly what you need.
You don't get that often with less than 2MB of library size these
days. <br>
</p>
<blockquote type="cite"
cite="mid:CALnHYQFGEJJMvMO9nkpMk0ZiDHGSgr=aKPBP8_O=atfCioW21g@mail.gmail.com">
<div dir="ltr"><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>
</div>
</blockquote>
<p>I am here. We still at least compile the gl backend. I fix bugs.
Now what? Have you fixed the PDF or quartz backend recently? Those
are not feature complete.</p>
<p>This is a bad argument of course. I hope you see why. </p>
<blockquote type="cite"
cite="mid:CALnHYQFGEJJMvMO9nkpMk0ZiDHGSgr=aKPBP8_O=atfCioW21g@mail.gmail.com">
<div dir="ltr"><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>
</div>
</blockquote>
We recently had a short discussion about dropping autotools
recently. There are a few things autotools does that are missing
from meson as for now. Mostly the release-packaging stuff. As for
me: I will not port that over. Maybe you should talk to Tim how this
could be accomplished. Despite of the fact that we currently use
autotools for cairo I would not really mind it disappearing.<br>
<blockquote type="cite"
cite="mid:CALnHYQFGEJJMvMO9nkpMk0ZiDHGSgr=aKPBP8_O=atfCioW21g@mail.gmail.com">
<div dir="ltr"><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"
moz-do-not-send="true">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>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:CALnHYQFGEJJMvMO9nkpMk0ZiDHGSgr=aKPBP8_O=atfCioW21g@mail.gmail.com">
<div dir="ltr"><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>
</div>
</blockquote>
<p>If you do updates frequently, I would advice to always use the
latest master version. Occasionally a new bug might be introduced
but if you look at the list of previous issues it might seem that
things can only get better.</p>
<p>I am not really into the tarballs thingy...<br>
</p>
<blockquote type="cite"
cite="mid:CALnHYQFGEJJMvMO9nkpMk0ZiDHGSgr=aKPBP8_O=atfCioW21g@mail.gmail.com">
<div dir="ltr"><br>
So, I guess my question is: would this plan be acceptable to the
people still involved with the development of Cairo?<br>
</div>
</blockquote>
<p>To give some information: We use cairo in a commercial product
and I got into development by fixing some simple issues that
occurred in that scope. Now I am deemed an active developer by
some people and try to have a look at merge-requests and new
issues. I occasionally do work on cairo that is not covered by the
commercial interest.</p>
<p>I would be fine with the removal of backends as I do not use
them. But when talking about responsibility I have to say, I do
not know. Every now and then someone comes along who does seem to
use the more exotic stuff. And - given that cairo is free and
open-source - what right would I have to remove code that
seemingly does not cause any problems? You say people enable stuff
and realize it does not work. You say it would ease development to
remove backends. From what I see I just cannot say I am sure, you
are right.</p>
<p>I do not feel comfortable making radical decisions on such an old
project.</p>
Regards<br>
Heiko<br>
<blockquote type="cite"
cite="mid:CALnHYQFGEJJMvMO9nkpMk0ZiDHGSgr=aKPBP8_O=atfCioW21g@mail.gmail.com">
<div dir="ltr"><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"
moz-do-not-send="true">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>
<br>
-- <br>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature"><a
href="https://www.bassi.io" target="_blank"
moz-do-not-send="true">https://www.bassi.io</a><br>
[@] ebassi [@<a href="http://gmail.com" target="_blank"
moz-do-not-send="true">gmail.com</a>]</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
</body>
</html>