Minutes for the GTK Team meeting - April 1, 2019

Minutes from the GTK team meeting on April 1, 2019

Attendees: Emmanuele, Benjamin, Allan, Carlos, Jonas, Jordan

Agenda: GTK team meeting agenda

3.96 snapshot (Matthias)

  • Time to get a snapshot out
  • New milestone: https://gitlab.gnome.org/GNOME/gtk/milestones/2
  • Small regressions all over the place
    • Menus
    • Type to search
  • Remaining child properties
  • Consistent naming of GTK demos and tools
    • org.gtk.* as the base name
    • Version number at the end of the name: IconBrowser4, Demo4, etc…
    • Schemas?
    • We can choose between: collisions between installed packages, weird dependencies, or slow settings drift
    • GTK settings are mostly state storage (FileChooser/ColorChooser/EmojiChooser)

Testing (Benjamin)

  • Benjamin has been looking off and on to testing infrastructure
  • Mostly for animations, but also for test breakage on CI
  • Unwritten policy: breakage on master should be reverted
  • Dependencies also make CI a bit harder than necessary
    • Not everything is under our control, or can be bundled using a subproject
  • Testing for render nodes
    • Needed a text format for describing render nodes
    • Then went through CSS features
    • Found out reftests are still disabled
  • Messy interaction between Meson and GTest: arguments are not preserved, names do not match, environment set up is
    easy to get wrong
  • Meson does not know how to set up a GTest unit
  • Missing link between tests output and GitLab: JUnit XML format
  • Can we push results somewhere so we can graph them? Tricky to do with CI, and unstable unless we have our own CI
    builder, but would be useful to track progress or flaky tests
  • Tests are still hard to write; missing infrastructure: input behaviour; windowing systems (e.g. clipboard);
    rendering backend (vulkan/gl/cairo)
  • CI pipelines for valgrind/strace/debug tools

Pattern review (Allan)

  • Reviewing design patterns for GNOME
  • What kind of design patterns can we commit to GTK?
  • Which ones are too complicated? Which ones can be simplified?
  • Conf call: Tuesday, April 2, 16:00 UTC

Interns (Emmanuele)

  • Lots of contacts for revamping the GTK website infrastructure, but only one that may stick around
  • Need to open issues for gtk-web to outline a contribution process and a roadmap
  • No takers for the testsuite, but with the tests still in flux/too complex for newcomers, we may have to punt
  • Subscribed to Google Season of Docs (like SoC, but for documentation writers); nothing concrete at the moment
  • We need to go through the issue tracker and find good newcomer bugs
  • Keep an eye out for Outreachy

4.0 status (Matthias)

  • 4.0 milestone
  • Latest attempt at making popovers separate top-levels
  • Moved focus handling, idle sizer, default widget, mnemonics, etc to GtkRoot
  • Popover replacement implementing GtkRoot
  • Next step: create a GdkSurface type mapping to xdg-popup
  • Found out xdg-popup is not enough for popovers: can’t move visible surfaces, focus handling has to be implement
    client-side from scratch
  • The X11 side hasn’t been fully fleshed out
  • End goal: large cleanup, dropping child windows
  • Still incomplete: removal of root coordinates
  • Open questions for popup surfaces:
    • what kind of API do they expose?
    • are grabs built-in or do we remove them?
    • auto-hiding as property
1 Like

Its interesting what data are you after here. Given that we want an always green master, the biggest data point which would be test-failures over time is out of the picture since there aren’t supposed to be any. This of-course assumes that flaky tests are either ignored or fixed and that the CI run is always consistent and provides the same results for the same commit and environment.

Once you take the above into a count, historic result become way less interesting. Then you can measure performance of benchmarks/tests. This though has a couple of gotchas, the environment might change, say an optimization in graphene or a regression in another part of the stack. You can’t really keep a static environment in the long term. This might be a good thing for the part of the stack that gtk “controls” directly, like glib, graphene, pango etc but everything will need to be reset the moment a change in something like pixman occurs. This will also need a dedicated runner for the benchmarks in order to have consinstant results. This will likely need to be a real hardware machine, no cloud vm, and only be able to run 1 job at a time. It will also most likely need to be frozen in time, no kernel updates for example which would impact the results and mess with the history.

The Flatpak runtime already ships valgrind and strace in the .Sdk extension. The CI images currently don’t contain .Sdk.Debug though cause the CI runners where timing out frequently, but this can be solved if we throw a machine with a better connection at it. We could certainly inlcude more tools in the .Sdk as well, I had my eye on asan fro a while now.

For the fedora/debian/w/e images it should be straight forward to add it the tools as well

I disagree.

Not because I think those results are the ultimate goal that we should look for, but because those results are vastly better than what we have today: nothing.

And once we have those numbers stored somewhere, we can look at them later and do stuff with them. For example, somebody wanting to do a web page to look at those numbers would have actual numbers to look at, and not just code an empty website. And somebody wanting to do benchmarks might actually write a few, just because those numbers get recorded.

And I’m also not sure that those numbers don’t provide any useful information, even with all the problems you listed. You can for example take the mean/average of the last 10 or so runs - that gets fluctuations under control. Or you can compare runtime of a single test against the other tests instead of just looking at wallcclock time, that gives you an indication if a test got slower/faster independent of hardware/load of the testrunner.

And then you can still go and bisect-rerun the test locally to figure out what was up with the questionable commits and which one is the problem.

But without any numbers, you will neither notice any problems nor will you have any ability to pin down problems.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.