[cairo] Release management for Cairo

Sun Apr 25 18:01:19 UTC 2021

On Sun, 25 Apr 2021 at 18:48, Petr Kobalíček <kobalicek.petr at 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 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
>>
>

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo/attachments/20210425/c34e5024/attachment.htm>