[cairo] Release management for Cairo

[Uli Schlachter]

Hi,

Am 25.04.21 um 19:12 schrieb Emmanuele Bassi:
[...]
> 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.

Welcome! By the power vested in me by the Bugzilla -> GitLab migration
(I still don't know whether "accidentally", but Heiko keeps pointing out
that GitLab things I am an "owner"), I just added @ebassi to the cairo
project with access "Developer". That's unlikely to be enough to make
releases (I honestly don't know), but I gave Heiko and Time the same
access level when I added them.

Welcome to a list of 97 members, five of which did not get this access
in the migration.

[...]> 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.

I'll try to go through the auto-mess and figure out what might still be
useful for general development. I will ignore anything that seems
release related.

Perhaps a better plan would be to start by making a list of what is
actually in there...

[...]>  - a better test suite integration, to enable parallelism and
per-backend
> options

What exactly do you mean with "per-backend options"?

For parallelism: What's the goal behind "parallelism"? E.g. for "faster
CI", one could parallelise by testing each backend in its own job.

>  - porting some of the existing tests currently written as shell scripts,
> and vetting their usefulness

Would it be okay to start with adding the existing shell scripts (that
seem useful) to meson? I guess this will break horribly on Windows, but
that's something that I cannot even test, so... yeah... Dunno

[...]
> As I said above, I am not really involved with the development of Cairo; I
> am just a downstream consumer of it.

That's exactly how I ended up here as well. :-P

[...]
>  - refactoring the test suite so that it can properly run on the CI pipeline

I'm currently working on have CI at least test whether the currently
passing tests continue to pass. See my recent PRs. Does that roughly
match with what you have in mind?

>  - fixing the cairo-www repository, and using GitLab pages for publishing
> the content

In case it helps: I have shell access to cairographics.org and can get
stuff from there. I didn't check carefully, but AFAIR the old releases
are currently only on there and not kept elsewhere. That would need some
fixing. Also, not only cairo has releases there, but also... uhm... I
think it was pycairo. I'm not entirely sure.

>  - doing a new development snapshot
[...]

Sure, feel free.

Does it make sense to do that before the removal of autofoo, just to see
what the current mechanism/mess is? If you already have a shell account
on annarchy, I guess that getting you added to the cairo group there
should be easy. If not, I don't know.

--------

For a new "real" release and since I remember you as one of the persons
with interest in color glyphs: How do color glyphs fit into cairo's
rendering model, as e.g. explained in [0]? What should happen if I
render a color glyph with a red source and operator MULTIPLY?
According to that tutorial text is just a mask and there is no such
thing as a color glyph: "The cairo_show_text() operation forms the mask
from text."

[0]: https://www.cairographics.org/tutorial/

I know this is somewhat offtopic, but this is the only "large-ish issue"
that comes to my mind that might prevent a release. Perhaps I should
check whether there was any new public API since the last release...

Cheers,
Uli
-- 
“Some people are worth melting for.” - Olaf