- Date: Monday 25th November 2024 at 16:00 UTC
- Location: https://meet.jit.si/Servo-TSC
- Agenda: #111
- Status update
- Roadmap
- Use of
cargo-vet - More self-hosted GA runners (build/test servers)
- Servo Contributors Process
- Crowdfunding
- Outreach
- AOB
Attending:
- TSC members: atbrakhi, emilio, gterzian, jschwe, mrego, mrobinson, nicoburns, wusyong
- Other: matlu, Michael Mc Donnell, Taym95
rego: Some highlights of this month:
Several things in layout: flexbox performance has been improved, parallel layout and caching, grid support with taffy, we have keyword sizes for replaced elements and we are working to complete that.
Good progress on WebCrypto API
ShadowDOM moving forward - used on many pages.
Improvements on tracing and integration with perfetto. Benchmarking report.
Basic IME and lots of fixes for OpenHarmony.
rego: We'll post the usual blog post this month with more details. Anything else?
rego: #109
rego: We've been discussing on this GitHub issue and now in a document as well for further refinement today.
rego: https://hackmd.io/@rego/servo-roadmap-discussion/edit
rego: Goal today to see if we agree and to discuss...find some agreement on goals for next year. Update web site and wiki.
rego: reviews proposals in document
rego: The ones with commitment we can accept easily as people have agreed already to work on them.
nico: This bullet point (embedding) excludes examplar UI. We just have egui. We don't have an impressive UI project that could turn into a browser that people could use at some point. Or decide that we don't want to.
yu wei: I can answer that question. For a long time, I had a grant working on Servo. I'm from the Tauri project. That's why I had the chance to work with Servo. This year, I had a side project called Verso. shows verso
yu wei: describes what he is focusing on with Verso / Servo. compositor efficiency during resizing, these are common usecases and features. They want resize to happen without stuttering. Where's the menu, etc?
yu wei: Maybe we come to a point where if we want Servo have a more ergonomic API we can combine the code we've made to propose a more ergonomic API to the community. We can follow in the topic in Zulip. I have opened a PR that adds another port. I think both approach is okay.
martin: we need to fill the dots between servoshell and the embedding API, servoshell should be on top of the embedding API
nico: what's the different between a port and an application?
martin: in WebKit for example, there's WebKit and a port is all of the platform specific bits for the embedding API
martin: before servoshell there was the winit port, as the platform specific was winit
martin: but we need a real embedding API and servoshell can be written on it
nico: that makes sense, but I agree there should be an API that doesn't depend on platform specific stuff
yu wei: My take is that we still have to rely on winit. We probably still want to stick to surfman, but I'm looking forward to glutin. There is project that does everything on its own that has issues porting to other platforms. That's why the majority of rust crates use winit and glutin. A more ergonomic API we should adopt it and move close to them.
jonathan: One thing I'd like to mention is that winit is very focused on user applications. We also want to focus on using Servo has a library. That might be difficult if we have a strong dependency on winit.
nico: One thing that a lot of rust ui projects have been pushing the winit project is types for things like keyboard events, etc that don't depend on the backend stuff in winit. That means you could have an api that is very easy to use from winit, but can be driven using any kind of embedding layer.
rego: Seems clear we want to keep working on the embedding API.
nico: about layout stuff My impression from discussions that we've had already is that layout can and should be independently usable library. Others are skeptical that this can be maintainable long term. My proposal is that we do both. We can leave it the time being where flexbox is internal and grid is the taffy one, but we could also have parallel implementations.
nico: Would allow us to do object comparisons in terms of performance and correctness.
rego: Maybe worth having a discussion on Zulip. Doing things twice probably isn't the best idea, but if we are using external library...
martin: before layout was serialized with script, and there were no benefits; but if there's benefit of having the split it's worth; if we don't get benefits it's probably quite complex architectural
martin: no opposition to experiment
martin: these all seem very important, trying to pick one more important is really hard; they all seem like things that we need yesterday
nico: I think that given the frame given this, this seems good as we have it. It would be good if we could start building out some kind of use of Servo ourselves and use that to drive what we work on. There's so many things that need fixing that it doesn't make a difference. We will get to the point where things will generally start working though and then it will be more important.
nico: Having a use of servo would help us focus.
gregory: Mats mentioned this to me and I looked into. cargo-vet is a tool from mozilla to have an overview of your dependencies to see if they've been audited for security. It's easy to set up, and then whitelist everything. Then you have a clear list of what isn't audited. There's a trust system. There's a lot of documentation that I haven't read in detail. In a PR you can mark a dependency as audited. It's information. We could set it up with a big whitelist and over time we could start that process and reduce it. Last thing I want to say is that I don't think we have many that have been audited, so this is an easy way to get started.
jonathan: Overall I'm a fan of cargo-vet. One point we need to raise is that just audited a crate is not sufficient is you have to re-audit on update. dependabot updates automatically, but we have to keep updating that list. It's not just an initial cost, but a constant cost with updates. We eventually have to start using it.
gregory: Is there some kind of decentralized community approach to this?
jonathan: Yeah, that's how it works.
gregory: We can probably set this up without any cost even if it's a bit meaningless. Are we okay to start looking into this and start using it.
nico: For me experimenting and talking about whether thing are audited is fine as long as we are not blocking things from landing. It seems like it could be useful to track the state.
gregory: I've opened the issue and this might be a nice project for first time contributor. I'd like to learn a bit more how it actually works. For instance, if Mozilla have decided if some crates have been audited. If everyone is okay that we just start using it as an experiment. I think it's a good first issue.
nico: Obviously this is something that we've started doing. We have some already. I've been looking at when my CI builds happen. The self-hosted runners are running much faster. I'm presuming this because of the self-hosted runner is capacity dependent. I'm suggesting we build out our build servers more. My suggestion if we maybe consider a macOS one as well. My question for the TSC is do we agree that more build servers are a good idea? Is there anything more specific that people think?
rego: I know that Delan has more information on the macOS runner.
martin: it's hard to have the conversation without Delan as she knows the most about it and has been doing the work
martin: obviously people want to do the CI fast
rego: Should be possible to keep improving this. I guess coordinate on Zulip.
rego: #111 (comment)
rego: I raised a proposal for how you can become contributor, maintainer, and TSC members. Contributors would be able to add labels to kick off try jobs and triage issues. Maintainers are people who can review, approve, and merge PRs. TSC members are people that can vote in the TSC.
rego: gives high level summary of proposal
rego: Questions / comments?
yu wei: I am generally okay with the proposal. Maybe for the cleanup of the TSC member after a year of no activity. Maybe we move it another role such as alumni. Several projects have this kind of position. It's like a position where we respect their contribution, but they are not here at the moment.
rego: Right now we have Past Members. We could iterate on that.
nico: One point that just occurred to me is for TSC members. You can also become one without the requirement. My point is that it's not a requirement in that case.
rego: martin: that point is to make it clear that becoming a TSC member without being a contributor is exceptional, and it's only for people that are not contributing technically to the project
rego: martin: if you're contributing to the project, you could get into through the regular path
rego: another way I see this is that people in the TSC that aren't working on the project as developers these days, then people like myself, manish, simon wouldn't really meet the new requirements.
nico: The other thing I want to saw, which I didn't say on Zulip is formalizing things like super maintainers that have access to GitHub project access rights. They have and no one knows. I guess it would be good to give roles responsibilities as well. Someone has got to go in and do tasks, right?
nico: We shouldn't block document and it doesn't have to exist. But formalizing it makes sense.
rego: Yeah, I agree we should document it, but we can do it as a followup.
rego: Nothing to highlight this time, as LFX crowdfunding platform has been closed already as discussed last month.
rego:
- Servo: Building a Browser Rendering Engine in Rust by Rakhi Sharma (Oct 2024)
- Solving Concurrency with (In-)formal Methods in Servo by Gregory Terzian (Oct 2024)
- Porting Servo to OpenHarmony by Jonathan Schwender (Oct 2024)
rego: https://blogs.igalia.com/mrego/servo-revival-2023-2024/
rego: We are really proud of the results. We've come a long way. No plans for conferences until maybe FOSDEM.
jonathan: Just wanted to ask if the roadmap still open? Can we add points before the next TSC call. I still have some points I didn't write down yet.
rego: The roadmap is going to be a live document. We can add more points during the year without problems. Maybe we can define a simple process for adding to the roadmap.
rego: thanks, everyone, the meeting is over