- Date: Monday 26th June 2023 at 15:00 UTC
- Location: jitsi
- Status update
- WPT pass rate dashboard
- Sync strategy for Stylo, Web Render and SpiderMonkey
- Embedding API
- Linear commit history
- Linux Foundation
- Outreach
- AOB
attending: atbrakhi, cybai, emilio, Loirooriol, matlu, mrego, mrobinson
rego: Main progress has been around floats. A bunch of patches landing. Most important part of work. Was totally broken, but the pass rate is starting to go up. Blocks are now floating, going to work on a few fixes, and after floating inline content.
rego: Layout 2020 has been enabled by default. Most things are using it as the default engine. We have a demo page now with demos that work in the new engine.
rego: Those are probably the most important things for now wrt development.
rego: https://wpt.servo.org/
rego: We have this new dashboard (above). Now it only shows the new layout engine by default.
manish: (here in chat but can't attend video rn)
mats: maybe this could be explained on the wiki.
rego: Regarding linking it on the wiki we are planning on having a small document explaining layout. We could have something there.
rego: I think Martin has been trying some things.
martin: we're using different strategies for each dependency
martin: I'm trying to do the WebRender upgrade, but it's big; and also it needs a bunch of patches on top
martin: maybe we can just use the WebIDL approach, with some patches on top, for other dependencies too
martin: this is something that Gecko already does, with third_party and some patches on top
martin: that list of patches can be moved upstreamed at some point
martin: this is important for WebRender, because WebRender has removed a lot of features that we need, and we need to keep them there before we can make changes to not need them in the future
martin: anyway in general I think we could have a couple of patches usually on top of these dependencies
emilio: as long as there's a way to essential reconcile both is fine
emilio: I think it's more clear than the current status of things
emilio: do you have a link with the plan? in general seems fine
martin: not yet, I'm trying with WebRender, to proof if it's a reasonable approach or not
martin: it probably makes sense to wait a bit for Stylo; probably it makes more sense to finish the upgrade before doing that
emilio: ideally for Stylo you only need to keep patches there temporarily
martin: that's the hope, and we don't have big differences
emilio: the whole threading setup has changed upstream
emilio: found a lot of issues with android scheduling, that the cost of switching to thread pool was being slower than doing the work in the same thread; we have a patch for rayon to allow the main thread (layout thread in Servo) to be part of the main pool
martin: the plan for me is to try to get the WebRender upgrade to a reasonable stage and explain that in a bug
martin: the controversial patch would be to move things into the main repository, but that might save us some time
martin: if we ever want to have these things in crates.io, probably we can manage this from vendored copies of those crates
emilio: we have the same publishing from mozilla-central for selectors (that need a patch) but we can publish from the main repo
emilio: the only place when it makes sense to have a repo outside servo, when we expect a lot of contributions there from outside, or when we think there are not going to be more changes in the future
martin: we have done a few upgrades, and having to do them between repositories, is not fun
emilio: a lot of wasted time and effort, I agree
martin: I was at RustNL a few months ago, talked to these folks that are making UI toolkits in Rust
martin: there are lots of interest in trying Servo and integrate it in their tools
martin: in general, when they write code in their tools, they like that in 1-2 mins you can do changes and get your binary
martin: but that doesn't work with Servo, that has a lot of dependencies and integrating with the project is not possible right now
martin: some of them are using the webview from the system with some wrappers
martin: the trick is that rust doesn't have a stable ABI
martin: so you might need to expose a C API
martin: from libservo
martin: and have a bit on top that consumes that C API, and expose it as a Rust API on top
martin: is a bit messy, that will allow us to ship a pre-compiled version of Servo that people can use directly on their projects
martin: projects like Tauri has written some sort of cross-browser engine wrapper, and we could implement the same kind of API
martin: it's a trick topic
mats: I think it's worth exploring, as a way to get more users and more interesting demos and more people interested in the project
martin: it's our hope that something like this could make embedding framework easier for our potential users
martin: maybe if we do this, it should be the only way to use servo and even the test runner could be using this, so we test it all the time
mats: hopefully in the same quarter we could make progress in the Android build, so it'd make sense to make easier for app developers to use Servo there too
martin: this is something we'd like to try
martin: sometimes it's hard to track down what changes come from each PR
martin: the idea here would be to use merge commits, which is very common in all the browser engines, and make things simpler when looking into the history
martin: right now we use bors, which cannot do merge commits; we want to try for a week or two, this new github merge queue
martin: it allows you to do squash strategy
martin: this will need collaboration from everyone working on servo and a bit of patience while we set it up
martin: the other benefit is that if it works we won't need to maintain bors anymore
emilio: it'd be great to get rid of merge commits; if github merge queue satisfy the requirements from CI and such
emilio: if bors has a feature for this it seems also fine
emilio: linear history is great
martin: maybe the incentive to do clean commits isn't as big when you can squash
martin: we need to kind of see how it is if we try
oriol: I agree with having a linear history, but for example when I'm importing stylo changes, I'm making a PR with a lot of changes; probably we shouldn't squash in those cases and just rebase in that case
emilio: yeah rebase seems better
martin: I wonder if there could be a way to select if you want to squash or not
rego: There was a poll to accept the charter. This has been accepted, so servo is a LFE project now.
rego: It's going to show up on the page soon. We've sent an announcement to the members about that.
rego: We plan to announce this at an upcoming event in a coordinated way.
rego: https://servo.org/blog/2023/06/19/conference-news/
rego: We published a blog post, martin and delan gave talks, we has some session at the WEH. Mats and myself will be at the Open Source Embedded Summit in Prague...we'll mention Servo at a talk and at the Igalia booth.
rego: We will do a lot more marketing in August/September around the events in Bilbao.
rego: If there are no other topics, thanks everyone for attending.