[cairo] Release management for Cairo

Tue Apr 27 12:25:35 UTC 2021

On Mon, 26 Apr 2021 at 16:55, Uli Schlachter <psychon at znc.in> wrote:

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

Thank you!

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

I've just noticed that the Meson build is not generating the API reference,
and fixed that, so I guess that's one issue down. :-)

I'll go through the Autotools build and see what can be salvaged, but
currently the Meson build is good enough to be used to build GTK and run
its tests/examples on Windows and macOS, which is a good starting point in
evaluating its readiness.

[...]>  - a better test suite integration, to enable parallelism and
> per-backend
> > options
>
> What exactly do you mean with "per-backend options"?
>

For instance, run the image tests by themselves, to fail fast on the common
baseline.

Then we detect the platform, and run the X11 tests on X11 (using Xvfb as a
wrapper); the Windows tests on Windows; etc.

For instance, GTK defines different test environments depending on the
enabled backends using the `add_test_setup()`:

https://gitlab.gnome.org/GNOME/gtk/-/blob/master/testsuite/meson.build#L17-49

The CI pipeline will then run the test suites using those setups:

https://gitlab.gnome.org/GNOME/gtk/-/blob/master/.gitlab-ci.yml#L84-86
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/.gitlab-ci/run-tests.sh#L14

Each test run has its own log and results report, which is also published
as part of the CI artifacts:

https://gnome.pages.gitlab.gnome.org/-/gtk/-/jobs/1269930/artifacts/_build/report-x11.html
https://gnome.pages.gitlab.gnome.org/-/gtk/-/jobs/1269930/artifacts/_build/report-wayland.html
https://gnome.pages.gitlab.gnome.org/-/gtk/-/jobs/1269930/artifacts/_build/report-broadway.html

(The links above are transitory, and will go away after a new pipeline is
started, but they can be downloaded from the GitLab UI)

In GLib we even run test coverage reports and publish them using the same
mechanism:

https://gnome.pages.gitlab.gnome.org/-/glib/-/jobs/1270446/artifacts/_coverage/coverage/index.html

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

Faster CI is definitely important; we can already parallelise the tests
through Meson by having multiple tests.

We can also annotate each test using a "suite", so we can skip tests that
are known to be slow, and run them on the CI using a scheduled job (e.g.
once a day) instead of doing that on every merge request.

>  - 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
>

Of course.

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

That's definitely a great start.

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

Yes, there are also bindings there.

We can ask binding developers to attach tarballs to GitLab as well; I'm
fairly sure the fd.o admins would like to have fewer people with SSH
access. :-)

The C++ and python bindings maintainers are known to the GNOME community,
so I might be able to ask them for feedback.

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

Yes, spinning up a 1.18.0 release that is basically 1.17 + current fixes
would be great. I'll make sure to open merge requests for the build fixes
in the tanis branch as well.

After that, 1.19 can be opened, for more invasive changes.

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

It is a larger issue, yes; it's also, sadly, how font rendering is defined
when it comes to blending glyphs.

Matthias is definitely the relevant person to ask; he's not following the
Cairo development closely, and he also is busy maintaining GTK, so he only
has windows of time in which he can work on the text rendering stack.
Nevertheless, he is willing to make things work.

Ciao,
 Emmanuele.

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