<div dir="ltr"><div dir="ltr">On Mon, 26 Apr 2021 at 16:55, Uli Schlachter <<a href="mailto:psychon@znc.in">psychon@znc.in</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">Hi,<br>
<br>
Am 25.04.21 um 19:12 schrieb Emmanuele Bassi:<br>
[...]<br>
> Ideally, I'd like to help with the maintenance of Cairo. I am not an expert<br>
> in the tesselation code, or in font rendering, or in the image scaling<br>
> code; but I can deal with making releases, keeping the CI running,<br>
> automating the website maintenance, triaging issues, and fixing the build.<br>
> More importantly, since Cairo is still a GTK dependency, I can spend my<br>
> work time on those tasks.<br>
<br>
Welcome! By the power vested in me by the Bugzilla -> GitLab migration<br>
(I still don't know whether "accidentally", but Heiko keeps pointing out<br>
that GitLab things I am an "owner"), I just added @ebassi to the cairo<br>
project with access "Developer". That's unlikely to be enough to make<br>
releases (I honestly don't know), but I gave Heiko and Time the same<br>
access level when I added them.<br>
<br>
Welcome to a list of 97 members, five of which did not get this access<br>
in the migration.<br></blockquote><div><br></div><div>Thank you!</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[...]> Additionally, I would drop the Autotools build from the<br>
repository, and<br>
> rely entirely on Meson. Maintaining two build systems is not anybody's idea<br>
> of "fun", and the extant Autotools build is basically running on cargo<br>
> culting alone.<br>
<br>
I'll try to go through the auto-mess and figure out what might still be<br>
useful for general development. I will ignore anything that seems<br>
release related.<br>
<br>
Perhaps a better plan would be to start by making a list of what is<br>
actually in there...<br></blockquote><div><br></div><div>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. :-)</div><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[...]>  - a better test suite integration, to enable parallelism and<br>
per-backend<br>
> options<br>
<br>
What exactly do you mean with "per-backend options"?<br></blockquote><div><br></div><div>For instance, run the image tests by themselves, to fail fast on the common baseline.</div><div><br></div><div>Then we detect the platform, and run the X11 tests on X11 (using Xvfb as a wrapper); the Windows tests on Windows; etc.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">For instance, GTK defines different test environments depending on the enabled backends using the `add_test_setup()`:</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="https://gitlab.gnome.org/GNOME/gtk/-/blob/master/testsuite/meson.build#L17-49">https://gitlab.gnome.org/GNOME/gtk/-/blob/master/testsuite/meson.build#L17-49</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">The CI pipeline will then run the test suites using those setups:</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="https://gitlab.gnome.org/GNOME/gtk/-/blob/master/.gitlab-ci.yml#L84-86">https://gitlab.gnome.org/GNOME/gtk/-/blob/master/.gitlab-ci.yml#L84-86</a></div><div class="gmail_quote"><a href="https://gitlab.gnome.org/GNOME/gtk/-/blob/master/.gitlab-ci/run-tests.sh#L14">https://gitlab.gnome.org/GNOME/gtk/-/blob/master/.gitlab-ci/run-tests.sh#L14</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">Each test run has its own log and results report, which is also published as part of the CI artifacts:</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="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-x11.html</a></div><div class="gmail_quote"><a href="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-wayland.html</a></div><div class="gmail_quote"><a href="https://gnome.pages.gitlab.gnome.org/-/gtk/-/jobs/1269930/artifacts/_build/report-broadway.html">https://gnome.pages.gitlab.gnome.org/-/gtk/-/jobs/1269930/artifacts/_build/report-broadway.html</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">(The links above are transitory, and will go away after a new pipeline is started, but they can be downloaded from the GitLab UI)</div><div class="gmail_quote"><br></div><div class="gmail_quote">In GLib we even run test coverage reports and publish them using the same mechanism:</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="https://gnome.pages.gitlab.gnome.org/-/glib/-/jobs/1270446/artifacts/_coverage/coverage/index.html">https://gnome.pages.gitlab.gnome.org/-/glib/-/jobs/1270446/artifacts/_coverage/coverage/index.html</a></div><div class="gmail_quote"><br></div><div class="gmail_quote"><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">
<br>
For parallelism: What's the goal behind "parallelism"? E.g. for "faster<br>
CI", one could parallelise by testing each backend in its own job.<br></blockquote><div><br></div><div>Faster CI is definitely important; we can already parallelise the tests through Meson by having multiple tests.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>  - porting some of the existing tests currently written as shell scripts,<br>
> and vetting their usefulness<br>
<br>
Would it be okay to start with adding the existing shell scripts (that<br>
seem useful) to meson? I guess this will break horribly on Windows, but<br>
that's something that I cannot even test, so... yeah... Dunno<br></blockquote><div><br></div><div>Of course. <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">
[...]<br>
> As I said above, I am not really involved with the development of Cairo; I<br>
> am just a downstream consumer of it.<br>
<br>
That's exactly how I ended up here as well. :-P<br>
<br>
[...]<br>
>  - refactoring the test suite so that it can properly run on the CI pipeline<br>
<br>
I'm currently working on have CI at least test whether the currently<br>
passing tests continue to pass. See my recent PRs. Does that roughly<br>
match with what you have in mind?<br></blockquote><div><br></div><div>That's definitely a great start. <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">
>  - fixing the cairo-www repository, and using GitLab pages for publishing<br>
> the content<br>
<br>
In case it helps: I have shell access to <a href="http://cairographics.org" rel="noreferrer" target="_blank">cairographics.org</a> and can get<br>
stuff from there. I didn't check carefully, but AFAIR the old releases<br>
are currently only on there and not kept elsewhere. That would need some<br>
fixing. Also, not only cairo has releases there, but also... uhm... I<br>
think it was pycairo. I'm not entirely sure.<br></blockquote><div><br></div><div>Yes, there are also bindings there.</div><div><br></div><div>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. :-)</div><div><br></div><div>The C++ and python bindings maintainers are known to the GNOME community, so I might be able to ask them for feedback.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Does it make sense to do that before the removal of autofoo, just to see<br>
what the current mechanism/mess is? If you already have a shell account<br>
on annarchy, I guess that getting you added to the cairo group there<br>
should be easy. If not, I don't know.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>After that, 1.19 can be opened, for more invasive changes.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For a new "real" release and since I remember you as one of the persons<br>
with interest in color glyphs: How do color glyphs fit into cairo's<br>
rendering model, as e.g. explained in [0]? What should happen if I<br>
render a color glyph with a red source and operator MULTIPLY?<br>
According to that tutorial text is just a mask and there is no such<br>
thing as a color glyph: "The cairo_show_text() operation forms the mask<br>
from text."<br>
<br>
[0]: <a href="https://www.cairographics.org/tutorial/" rel="noreferrer" target="_blank">https://www.cairographics.org/tutorial/</a><br>
<br>
I know this is somewhat offtopic, but this is the only "large-ish issue"<br>
that comes to my mind that might prevent a release. Perhaps I should<br>
check whether there was any new public API since the last release...<br></blockquote><div><br></div><div>It is a larger issue, yes; it's also, sadly, how font rendering is defined when it comes to blending glyphs.</div><div><br></div><div>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.</div><div><br></div><div>Ciao,</div><div> Emmanuele.<br></div><br clear="all"></div>-- <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>