Servo TSC Meeting July 2024

[mrego]

• Date: Monday 29th July 2024 at 15:00 UTC
• Location: https://meet.jit.si/Servo-TSC

Agenda

• Status update
• Stylo release
• Taffy
• Plans for Flexbox/Grid support
• Crowdfunding
• CI runners proposal
• Outreach
• AOB

[delan]

CI runners proposal

In the May 2024 meeting, we discussed the idea of renting a dedicated server for CI runners. After further research and prototyping with @sagudev and @nicoburns, we would like to make an updated proposal.

We would like to spend 104 EUR/month on a Hetzner AX102 to cut build times on our full cross-platform main and try builds by 32%. By making those workflows select a self-hosted runner only when available, we can do this in a way that enhances our existing CI setup without locking us in.

For a detailed analysis of build times and the alternatives we considered, see this comment. There have been a few changes to our proposal since then:

• The cost of the proposal is now 104 EUR/month (was 184.21 EUR/month), because using Open Source Collective’s billing address yields 0% VAT, and using Windows 10 for the Windows builds reduces licensing costs [^1].
• We asked GitHub if they could sponsor larger runners (much easier, much more expensive), but they declined.
• As a result, this proposal is now by far the cheapest way to accelerate our Windows and Linux builds.

We will use this server as a hypervisor, creating ephemeral virtual machines for each build as recommended by GitHub. These virtual machines will have more CPU and RAM than GitHub’s free CI runners, and they can be cloned instantly from custom images that prebake all of the necessary tools, dependencies, caches, and even a prebuilt copy of Servo, allowing us to skip mach bootstrap and take advantage of incremental builds.

servo/ci-runners is a proof of concept, including virtual machine configs and a service to create and manage CI runners. To play around with it locally, you will need a Linux machine with libvirt and zfs. Work is still ongoing on updating our CI workflows, but our early testing shows that we can run the Linux build job in 8 min (down from 29 min) and the Windows build job in 12 min (down from 61 min).

Screenshot of runner service


[^1]: Windows 10 can run indefinitely in evaluation mode with negligible side effects. Switching from Windows Server 2019 to Windows 10 also allows us to run as many concurrent Windows runners as we like, because Hetzner servers need a special kind of Windows Server licence called SPLA, which only allows one virtual machine per licence in the Standard edition, not two. We asked Hetzner if they would be willing to let us rent two Standard edition licences for one server so we could run two concurrent runners for cheaper than a Datacenter edition licence, but they declined.

[nicoburns]

I have a few points for the Agenda:

1. Stylo (and related crates) release

• It seems like we are close to being ready for this.
• Crate metadata updates: will these be done upstream? (@emilio - would you be willing to accept crate renames, version bumps, etc upstream?)
• Plans for upstreaming remaining diff from mozilla
  • would it be helpful for me to work on this?
  • style_config seems like a major piece that should be easy to upstream
• Blocking issues:
  • Mako build failure
• Versioning scheme (version numbers, etc)
• Commitments: Changelog? Examples? Release schedule?

2. Taffy

• What is the TSC's disposition towards depending on it for Flexbox? Grid?
• Current state:
  • Better WPT results than existing implementation, but not wildly so (72.3% vs. 55.7% on main)
  • Real-world results are much better - the web is usable - but implementing columns in the existing impl would likely get us close.
  • Some missing features (calc, correct abspos)
  • Perf issues are the same ones that we would need to solve for columns in current impl
  • CSS Grid implementation "for free" (same integration code as Flexbox)
• My analysis:
  • Short term (days/weeks): has better support than existing Flexbox impl (we could merge it "today" and have much more of the web usable).
  • Medium term: (weeks/months) it probably makes little difference. The existing impl can absolutely catch up. And we have the engineering resources available to do that.
  • Long term (months/years): having layout in an external, permissively licensed library seems like a big win to me:
    • Lowers barrier to entry to contribute to layout (don't have to compile whole of Servo, can use unit-testing setup)
    • Code can be shared among projects (future dev work like subgrid, writing mode, etc can be shared)
    • Is a good engineering practice to have clear abstractions and hide implementation details. Taffy already has that abstraction worked out.

3. General plans for improved Flexbox/Grid support

• Flexbox: What are the plans?
  • Should I try to help? Should I stay out of the way?
  • Would it make more sense to do more up-front design/planning/triage to enable parallel work?
• CSS Grid - Should I start laying groundwork:
  • Adding feature flag
  • Enabling WPT tests
• Intrinsic sizing keywords (#32853) a notable blocker for flexbox/grid WPT tests

[emilio]

Crate metadata updates: will these be done upstream? (@emilio - would you be willing to accept crate renames, version bumps, etc upstream?)

Sure, that's fine. I can't make it to today's meeting because of a conflict, but you know where to reach me :)

Blocking issues: Mako build failure

Can you provide more details?

[nicoburns]

Blocking issues: Mako build failure

Can you provide more details?

This one's just on our end (Gecko is vendoring the mako python library in it's 3rd-party directory, Servo is still using a python "wheel" for mako committed in the repo (in the style/properties dir) but we broke that patch in the recent sync)

There is perhaps a wider question about the best way to deal with code/resources that Stylo references from outside the servo directory in mozilla-central. I would ideally like to move away from conditionally compiled code and towards generics / dependency injection where this is possible and doesn't cause an undue burden on maintainability (or unacceptable runtime costs).

It seems that Stylo is the main usage of mako in the Gecko repo (?), so in this particularly instance we could consider migrating to a rust-based templating solution. We could also consider committing / publishing the generated code so that mako becomes a dev dependency but isn't required by consumers of Stylo.

[emilio]

Yeah, not opposed to migrate to something else! Mako is an odd choice these days, the choice predates rust proc macros, and all the #[derive]s we have nowadays. In fact I raised this internally not long ago as one of those "tech debt" kinda things that would be great to fix :)

The main requirement I think we have in Gecko is being able to access CSS property metadata from outside the rust build system (I think mostly for devtools and use counters etc). That probably makes "pure" rust proc macros a harder solution, but yaml / json / etc would be straight-forward to migrate to (still a bunch of work tho), and we could use that as an input during the build system to generate as much rust code as we need.

[jdm]

I can't attend the meeting, but I would like to register my support of relying on the taffy integration work that Nico has been doing. While I don't really have a stake in how the layout parts of Servo are implemented or maintained, I find the vision of sharing code with other projects compelling. It feels like the choice we made with the media stack to use an existing integration with gstreamer rather than continue to decouple gecko's media engine