- Date: Tuesday 28th May 2024 at 15:00 UTC
- Location: https://meet.jit.si/Servo-TSC
- Status update
- Crowdfunding
- Proposals/ideas to use the money
ReadableStream- Vello integration update
- Crate ownership discussion
- Criteria for publishing stylo
- Changelogs
- Speedometer performance test suite
- Outreach
- AOB
Attending:
- TSC members: atbrakhi, emilio, gterzian, Loirooriol, mrego, mrobinson, nicoburns
- Other: jschwe, matlu, Mikopet, ststimac, wusyong, zrhoffman
rego: Lots of progress on font system. Now support emoji and many improvements. Progress on flex and tables. Both layout modes progressing. New DOM properties implemented. Fix for event loop to follow spec more closely. Android build fixed allowing Servo running on more phones. Servo book is WIP, but now published.
rego: https://book.servo.org/
rego: We will post the usual blog post.
rego: We have documented how the fees work for the different funding methods. The Linux Foundation is still active, they still haven't moved the money and closed the account. We have some money available in OpenCollective.
rego: https://servo.org/sponsorship/
rego: #88 (comment)
rego: We could make a small group of people setting this up if folks think it is a good idea.
rego: From the experimentation from Delan, the Windows build was reduced from 60 minutes to 15 minutes and Linux from 30 minutes to 10.
nico: Will monthly income cover that?
rego: Yes.
yu wei: Currently the streams implementation is a patch on mozjs. Our next major mozjs update will be this summer. So it's probably better to look into this again.
martin: I think Josh's PR only disables the use of ReadableStreams in mozjs
martin: that's part one, but then we have to implement it; it'd be nice to don't remove it until we implement it in Servo
yu wei: I guess we want to keep it in the next mozjs
martin: how big is it?
yu wei: it's actually pretty big, like 10,000 LOC or so
gregory: I met with the Vello team at RustNL. Interesting in exploring this further. I'm personally also interested. Do we have consensus that we want to look for a replacement for raqote?
rego: just for reference, previous discussion on this topic: https://github.com/servo/project/blob/main/governance/tsc/tsc-2024-03-25.md#servo-and-2d-canvas-vello
martin: I personally don't see any issue with moving to Vello in principle, I agree we should move away from raqote (as it doesn't have active development)
martin: it'd be no ideal to switch to Vello and be in the same situation than we're now with raqote; it'd be nice if Vello could stick around for years if we switch to it
martin: it would make sense if we don't remove canvas features when moving to Vello
nico: the main disadvantage that vello brings is that it bumps the hardware requirements in that it requires wgpu. You need Vulkan, Metal, or DX12.
sagudev: wgpu also has gl support
gregory: Yeah, if we switch we want something that's going to stick around. It would be idea if we wouldn't lose features while switching. What nico mentioned...I don't know about those details. We already rely on wgpu for WebGPU.
rego: we've discussed this previously at https://github.com/servo/project/blob/main/governance/tsc/tsc-2024-04-29.md#crates-maintenance
gregory: I was also looking at the charter (?) permissions. Committers aren't necessarily members of the TSC. Can we have people who are maintainers who are not members of the TSC?
gregory: I think we could add people as committers who aren't TSC members. Perhaps we could add a table to the Servo book where we could write who are the committers on that.
rego: Just a quick clarification. I think we already have committers who are not TSC members. I think that's totally okay.
martin: about a section on the Servo's book, GitHub have these code owners files; which are very nice as it adds people on reviews, and it's per directory so that allows a more complex system of ownerships; we can generate the section of the book from this
martin: we can start adding code owners right away
gregory: Sounds good. Especially if we can generate some documentation based on code owners. I'll look into it and we can discuss it formally in Zulip.
nico: Can we move to a more formal process for publishing crates?
nico: Instead of solving this in general, perhaps we could try to do this for Stylo.
martin: do you mean criteria for when it's ready to publish, or how often?
nico: both
martin: whatever release rhythm we use, it'd be nice if we link our updates with stylo upstream; maybe one requirement is to uplifting our changes to style upstream in gecko
nico: is there a reason why this blocks the release?
martin: maybe due to churn on the API, I think it'd be nice to remove Servo specific code in stylo before we can do a release; it's still there as it was part of Servo before
nico: related to syncs, for WPT we have a two way sync, could we do something for stylo?
martin: we do have a sync for stylo, a bit different than the WebRender; you decide when to move to a branch
nico: I did talk to some people that work on ??? at Mozilla, that they use some other projects
martin: it used to be that way, but that has changed
nico: sounds like the main next step, is to get rid of Servo specific code
nico: It sounds like the main next step would be get rid of the Servo-specific code that doesn't need to be Servo-specific.
nico: would you be happy for me to change the crate name and update repository links in the meanwhile
martin: which crate?
nico: the style crate
martin: I guess we can coordinate this with Oriol
nico: One of the things that is not great is that there is no public changelog for what's actually changed between versions. Would people commit to maintaining changelogs?
rego: I'm not sure how often we are publishing crates from the Servo project. Do we do that just when we need them for Servo.
martin: right now is when we need them in servo, or when folks ask us to do one; there are a lot of crates
rego: One big issue is the amount of work this will imply while we don't have people with a lot of time to maintain these crates. We are doing the bare minimum now.
nico: I wouldn't commit to maintaining every single crate, but I would pick a subset and commit to releasing them every three months -- depending on the amount of changes.
martin: I think we almost always release, most of the changes are because of dependencies bumps, and we typically release after those
martin: what might make sense is to having a more systematic way of bumping dependencies, but it's a lot of work, so it's hard to say
nico: this is also getting into releases of servo itself, that could be every X months
gregory: The good news is that I was able to run Speedometer locally using the Servo WebDriver server. It doesn't really run any tests at this point. It seems to work, but it wasn't written in a way where a missing features is recoverable.
gregory: We would have to fork Speedometer and remove test cases that only Servo can't run.
gregory: I heard that we have another Outreachy event in June. If I were to clarify a bit what could be done.
rego: We are also tracking missing features for other things. We could add handle this through the feature tracking Zulip steam.
nico: I think one of the features missing is contenteditable which Servo probably won't support any time soon.
nico: Most of the tests aren't doing anything too crazy. So it shouldn't be an unachievable goal.
gregory: Yes, contenteditable is part of the test suite. I don't know exactly what all the tests are using so it's probably a good idea to do that.
gregory: We could add the ability to choose the subset of tests to run. It's unlikely that upstream would accept that.
rego: We have labels on GitHub for good first issues, etc. The more we have of this the better.
rego: This month Gregory had a talk about Servo at GOSIM Europe. Folks were there and also at RustNL. Next week is the Web Engines Hackfest which will include a lot of us.
rego: There will be a breakout session next Tuesday, 3pm CEST. People can also join remotely.
rego: Tuesday 4th June at 15:00 CEST
yu wei: There is an integration with Tauri which exposes some Servo features. Interesting experiment. It's a project based on Servo, not a fork. I'm not interested in adding every possible feature. I mostly care about multi-view. It's a consumer Servo. I hope it can grow into a browser.
martin: it's an interesting idea and it's cool to see someone consuming Servo, it'd be a nice moment to figure out if the "embedding" API we expose is good enough; or how a full embedding APIs would look like
yu wei: I prefer this way, I've seen other projects and it's very complicated and very difficult to do the embedding
nico: I've been looking into the layout codebase, and I have some questions; I'll be organizing some call with the experts on that code to go over them