- Date: Monday 28th October 2024 at 16:00 UTC
- Location: https://meet.jit.si/Servo-TSC
- Agenda: #105
- Status update
- Roadmap
- Project priorities/goals
- Tracking priorities
- Future of
rust-url - AI policy update
- License policy
- Crowdfunding
- Outreach
- AOB
Attending:
- TSC members: atbrakhi, gterzian, Loirooriol, manishearth, mrego, mrobinson, nicoburns, wusyong
- Other: hsivonen, jschwe, matlu, Meng Tan, Taym95
rego: Lots of new contributors and contributions. Including Outreachy students working on clippy issues. More work on the layout engine, specifically on flexbox which has some caching support and intrinsisic sizing support in several layout modules. Work on fonts and performance reducing resource usage. We have started an initial benchmarking report in many years, comparing Servo to Chromium. There have been updates for WebGPU and many other things.
rego: https://github.com/servo/servo/wiki/Roadmap
rego: There was a request to update the roadmap determining top priority of project. This varies throughout the community. We can ask folks today or open a Zulip topic asking what peoples' priorities are. We can update the roadmap to address things that were there before (maintenance, CSS, embedding, etc). We can update it for next year.
rego: In Igalia's case we will be working on the layout engine. We are still finishing the flexbox engine getting it to a place where it is usable by all websites and it performs well. There are still many HTML/CSS missing features. We'll be focusing on that. We'll also be working on performance and optimizations, focused mainly the layout engine. Our hope is to confirm that paralellism can improve the performance of a web engine.
rego: https://github.com/servo/servo/projects?query=is%3Aopen
rego: There's a project on the Servo GitHub. We can track our priorities there.
rego: You can work on many different things in Servo as there are many things to do (WPT pass rates, focusing on a single site, add full support for a known framework like react, or maybe try Servo with the top web sites, or improve scores in benchmark suites). There are many different goals for the project and many different areas where people can try to work.
martin: seems like our big priority should be to be useful
nico: Can we be more specific about how we might be able to be useful? There's a lot of different ways that we can be useful. It's clear that I have a different vision. Can we write what existing contributors are planning to work on and are aiming for and have a process for new contributors to feed into that process saying, "I think this would be good and I have this usecase."
rego: The point today is for people to say their goals. Of course not everyone is here now, but if people would like to share their plans.
martin: by being useful, as a web engine, servo should be able to render web content that is out there in the world, reliably without missing features; when pages require a set of baselines features to work, Servo should be able to provide them, or make the page functional
yu wei: For myself, my end goal is to provide a usecase where everyone can use Servo. A simple web view library should be easy, but the tricky thing is how to accomplish the niche caches. Today I was using the multidocument support and I found a resize issue. I think people will complain about these issues. I think the philosophy that "Servo does things, but has a few downsides means those downsides accumulate." I think the adding the benchmark is important to see where the bottlenecks are and what's missing.
yu wei: I think another important thing would be some sort of tool to see the status of web features. I know that stylo already outputs something we can process. I want to do that once the benchmarking features is done. I know that Google has a page like this for Chrome. This could be very useful...the 80/20 percent rule.
yu wei: A lot of times only 20% of features are really useful.
nico: I'm interested to know what people think the blockers are. There's layout, but with the changes now, many pages look fine, but script things are missing. I wonder if there's performance things. I was trying google.com but it's very slow. The search box lags. The minibrowser is better than it was, but it's really basic. We don't do versioned releases.
rego: I think the point about usage is not about people using servoshell as a browser. It's a very playground for us, but mostly that a project like verso can use Servo and people use verso.
rego: I don't think versions of the servoshell are critical. There are lots of reasons why people don't use servo. Up until recently the lack of flexbox support was a blocker. Now, the lack of HTML forms are an issue. We don't have carets. There are a bunch of things broken that many people can identify as a problem.
nico: I think we need to fix the blockers, but I also feel like we need to have some selling point. At the moment we are worse in a lot of ways, but are there ways that we are better? I guess that's for me why a modular angle is a good one or we can optimize binary size and be smaller than other engines. Even if you get Servo to the point where it's rendering web content, why use it and not CEF?
rego: From my point of view be that if you are a Rust application or framework then you might prefer to use a rust engine. Servo is essentially the only choice here. In theory, that's why we are checking the benchmarking with Chromium. If you have multiple cores, then there's the possibility of being faster than Chromium. Then there is the memory safety point you mentioned. That's the situation now...in the future is a different question.
nico: To step back a bit, I think if there's things that people can help then the wider community could get involved. We had this discussion earlier...we don't have that many contributors to Servo considering how many contributors it is. It seems like there's potential to attract more contributors to Servo. Being a bit more public about what we are going to work on before we work on it.
rego: We aren't getting many plans from folks here. Maybe the meeting isn't the best place to get those.
rego: The next point is about the future of the rust-url repository.
henri: From my perspective my issue is can I proceed with the code I currently have, will someone be unhappy with it or will it violate any policies. I rewrote the internals code to use icu4x. That resulted in faster performance / small binary size as soon as you don't have something else as the unicode internalization crate. It resulted in a later MSRV and longer compile times and people were unhappy about that. It was rolled back due to those issues. I discussed it with the rust-url maintainers and I made a plan to make an application selectable Unicode backend and last month we had a licensing discussion. We'd have a problem if it wasn't okay.
henri: So I have these two crates that are part of this approach of unblocking those who are okay with using icu4x and people who want to use a different backend to use that.
henri: That's under my account, but it might look bad if it moves from the Servo org to may GitHub account. There's was a bit of pushback and whether it was appropriate to spin out the project. I feel like this is a bigger thing that I want to solve. All I want to solve right now is whether I would do anything bad policy wise. If Servo doesn't want them under the Servo, but I don't want to block that code on some sort of bigger discussion. The reason they are in separate respos is that it's useful for development. Putting them in the same repo, but it's easier for development that they are in separate repos. If there is a Servo-side feeling that rust-url is not under my GitHub account. I want to proceed. I don't want to be in a situation where the better (faster, smaller) rust-url isn't available.
matin: Servo organization has a lot of repositories, and many are archive now, but having so many is overwhelming; the folks working in rust-url are fairly independent, and it seems weird they have to ask Servo for things, as rust-url folks have probably more knowledge; not that we don't want you, it's great, but we've a different experience; and rust-url has grown a lot
henri: If the broader feeling is that it's weird for you all that I have permission, then the next step is for me to publish those under my GitHub account.
manish: I would like rust-url to stay as a Servo thing. I think rust-url shouldn't have to ask TSC for this, but I would like TSC to be involved. I wouldn't want rust-url to be run be icu4x. Giving it a bit more freedom, but ultimately giving it more decision making power is good.
manish: From a Servo perspective I think it would be good to make sure that rust-url stay a compliant URL parser, which is different from URL parser in other usecases.
martin: thanks for your perspective; to answer henri's point about publishing under your own repository, from my perspective that's totally fine and it shouldn't block things; my main concern is about managing all the number of repositories, maybe having two GitHub organizations, and saying that rust-url is a sub-organization of Servo
manish: that works
martin: maybe we can imagine Servo to be a big board member in the board of rust-url
nico: I understand that Servo has a ridiculous number of crates to maintain, but I also feel like we are making it hard for ourselves.
nico: There's some overhead to releasing crates. We've caused this, but for rust-url and all sorts of crates, we should be delegating responsibility and can act independently.
manish: It's worth noting that before the TSC that these crates should be used by lots of people and have users and decisions were made by whoever is active on these crates have a bit more decision-making power. We had people coming on WebXR and helping. The goal was that more people use them. One result was the triomphe crate. I never had to look at decision for the GL crates. I think that's an okay model.
martin: I can give 2 concrete examples of how this has been difficult recently; we switched recently to use the merge queue and use the main branch instead of master, that was a big project that took weeks, it's a lot of work because we have a lot of crates, it falls in the people that wants to have this code going in the same direction
martin: another examples is about using the same GL bindings, and it's taking weeks
martin: these are things important for maintenance
martin: I guess my thought is that if we can reduce that work, maybe that's good
nico: I guess I feel like part of the problem is that we need more people to do it. If we want to update them, that's going to happen if they're external or not. I have funded time to work on all of this stuff and no one has involved me in it.
nico: Stop having strict review processes so that something gets done.
henri: There's already an external dependency on my GitHub account. The ideal thing would be to treat them as third-party dependencies, but it looks like I take some code from Servo and put it under my account. If you don't want to deal with governing them right now, then maybe we can figure out what to do.
henri: I would like to proceed.
martin: I'd like to propose that we trust you from the TSC, and you keep this in your GitHub account for now
manish: I'd prefer to be an organization
henri: valentin already has access to the repos and the crates
manish: that's fine
martin: so that unblocks the situation and we can decide later about the rust-url separation later on
henri: for clarity I publish on crates.io while the repos are still in my GitHub account, and I offer to move them to other organization, and I'll add manish as maintaner
martin: yeah, thank you
rego: servo/book#27
rego: This was mostly a warning for people letting them know that AI tools for Servo often give wrong answers when you ask them about Servo.
rego: https://github.com/servo/project/blob/main/governance/CHARTER.md#7--intellectual-property-policy
rego: We discussed in the last meeting to write a policy, but we already have one int he charter!
rego: Anything open source is okay as long as it is compatible with MPL.
rego: We have managed to arrange with LF to close the LFX crowdfunding site. Finally closed after months of waiting. Everything goes to Open Collective.
rego: There were a few talks about Servo this month. In GOSIM China Gregory talked about Servo, but I don't think there is video. Rakhi talked about Servo last week at the Ubuntu summit and also at the LFE Summit last month with a published video.
rego: If there are events next year where folks are talking about Servo, we can make some noise about it. I guess November and December are slow months.
nico: Am I wasting my time on this modular Servo stuff?
rego: Open source takes time...people are busy...about the modularization, I don't know if people can answer that. If I put the time in to write this code and make releases, will that be something the project will pursue.
martin: the question is hard to answer because it's very general
martin: is there something specific you have in mind, a specific kind of modularity; maybe put an idea on the bugtracker or on zulip and then if people are onboard write a PR
nico: The thing that I'm most keen on is making release of stylo crates and writing changelogs, etc.
rego: I want to put my time and do this for the past several months, but I feel blocked.
martin: the thing that was missing here was a bit of organization, the things that work for us for a while; oriol has been doing a lot of work to update the version of stylo in the repo; and then update the version in Servo
martin: it's up-to-date now, and it wasn't last year, so we did a massive amount or work
martin: the missing part is writing the changelogs, PRs, etc.
martin: do you want us to put you in the loop, so you can help with some releases?
nico: that seems a good idea
martin: closes meeting