-
-
Notifications
You must be signed in to change notification settings - Fork 7
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add minutes for TSC April 2024 call (fix #85)
Co-authored-by: Martin Robinson <[email protected]> Signed-off-by: Manuel Rego Casasnovas <[email protected]>
- Loading branch information
Showing
2 changed files
with
237 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,236 @@ | ||
| # Servo Technical Steering Committee Meeting | ||
|
|
||
| * Date: [Monday 29th April 2024 at 15:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?msg=Servo%20TSC%20Meeting%20April%202024%20(2024-04-29)&iso=20240429T1500) | ||
| * Location: https://meet.jit.si/Servo-TSC | ||
|
|
||
| ## Agenda | ||
|
|
||
| * Status update | ||
| * Contributors/PRs stats | ||
| * Layout discussion (changes required to support Flexbox or Grid) | ||
| * Future of rust-harfbuzz crate | ||
| * Crates maintenance | ||
| * AI generated PRs | ||
| * Crowdfunding | ||
| * Outreach | ||
| * AOB | ||
|
|
||
| ## Notes | ||
|
|
||
| Attending: | ||
| * TSC members: atbrakhi, cybai, emilio, gterzian, Loirooriol, Manishearth, mrego, mrobinson, nicoburns | ||
| * Other: jschwe, matlu, Peter M, richarddushime, ststimac, zrhoffman | ||
|
|
||
| ### Status update | ||
|
|
||
| rego: A lot of work by many different people. We have just published the [summary blog post](https://servo.org/blog/2024/04/26/acid2-servo-book-qt/). | ||
| * Acid2 is passing against with Layout 2020 | ||
| * The WPT pass rate continues to improve. | ||
| * The Servo book is in progress. | ||
| * Stylo is now in-sync with upstream after a lot of time working on this. | ||
| * Many, many improvements including work on fonts. | ||
| * Work from folks on KDAB embedding Servo in a Qt application. | ||
| * Multiple webview change has no landed. | ||
| * The prebuilt SpiderMonkey change is now landed. | ||
| * [There was a blog post about SpiderMonkey / Servo / other JS engines](https://servo.org/blog/2024/04/15/spidermonkey/). | ||
|
|
||
| rego: It's been a great month. Thanks for the contributions. | ||
|
|
||
| rego: Some stats of 2024 vs 2023: | ||
|
|
||
| | | Number of unique contributors | Number of PRs | | ||
| |---|---|---| | ||
| | 2023 | 54 | 673 | | ||
| | 2024 (until April 26th) | 59 | 547 | | ||
|
|
||
| rego: Already this year, we've had more contributors than all of last year. Lots of new contributors from Outreachy. | ||
|
|
||
| ### Layout discussion | ||
|
|
||
| nico: The reason this has come up is because I have been looking at implementing column support for Flexbox. Blocking us from turning flexbox on by default. | ||
|
|
||
| nico: Looking at what I can axis of children. If I want the block direction size of the flexbox item, I have to perform a full layout, but the flex algorithm will call that function multiple times within the layout of a single container. If you next flexbox containers and they are all calling layout multiple times you end up with bad performance. | ||
|
|
||
| nico: I'm also not familiar with inline layout. Are there cached inline size that we might need to keep? | ||
|
|
||
| martin: in the flexbox algorithm, you should be able to get the flow | ||
|
|
||
| nico: The flexbox algorithm requires you to measure and sometimes relayout depending on how things flex. | ||
|
|
||
| oriol: I'm thinking about blink there were various cases where if you keep nested, it became exponential. I think for LayoutNG they avoided this they used caching to avoid this. Maybe we can check what they are doing and try to adapt it into Servo. | ||
|
|
||
| martin: that's not always the case, sometimes you have to do relayouts, depending on the layout mode (it happens sometime for floats and min|max-size situations) | ||
|
|
||
| nico: So you might have to cache. The cache we had in taffy was 500 bytes per node. Maybe you can optimize that. | ||
|
|
||
| nico: I might look into querying against the LayoutContext. I'll start by laying out and then seeing how it works? Does that seem okay? | ||
|
|
||
| ### Future of rust-harfbuzz crate | ||
|
|
||
| martin: last year servo has over like 100 github repositories, that's a lot to maintain for a small team, we've going through and checking which are still active or use and archive the ones that aren't, combine then when it makes sense, a lot of times they were used only by one crate | ||
|
|
||
| martin: there's a couple of interesting edge cases, rust-harfbuzz is one of them | ||
|
|
||
| martin: it's a low level API, which servo uses; and a high level one, which servo doesn't use | ||
|
|
||
| martin: and there's an official harfbuzz that provides the high level API | ||
|
|
||
| martin: Behdad has say they'll be ok adopting things we cannot maintain anymore, would it make sense to give up ownership of these crates | ||
|
|
||
| martin: one option is give up on the high level API we're not using, or give up in both of those and then the harfbuzz project would be responsibly also for maintaining it | ||
|
|
||
| martin: another option could be transfer both, the issue might be if Servo needs a new version at some point | ||
|
|
||
| manish: I'm happy to at least maintenance mode maintain the crate. I think that could work. | ||
|
|
||
| manish: If we want harfbuzz-sys to be in Servo and to have one of them maintained by a broader team. | ||
|
|
||
| martin: that raises another question, harfbuzz has its own high level bindings, not sure if they have a different philosophy | ||
|
|
||
| nico: the harfbuzz one hasn't been updated for 9 months | ||
|
|
||
| martin: Ours look better now, but that was only after some recent work making changes. Before that there was a gap of a few years. | ||
|
|
||
| manish: I like harfbuzz-rs, the crate we have, it's useful; if there's not a lot of effort to maintain it; there's not a big deal having two crates; the one we have works pretty well | ||
|
|
||
| martin: are there features in the C API that are not yet in our high level bindings? | ||
|
|
||
| nico: I wonder the fact they haven't updated their bindings, it means the API hasn't changed a lot recently | ||
|
|
||
| manish: harfbuzz rarely changes the API | ||
|
|
||
| martin: would it make sense to split? | ||
|
|
||
| manish: I'd have it in the servo org, the harfbuzz org or in its own org | ||
|
|
||
| manish: having an user in tree is useful | ||
|
|
||
| martin: other projects (like freetype-sys) don't have it | ||
|
|
||
| manish: that's a different case, and it's only used in Servo | ||
|
|
||
| martin: I was referring to the one by PistonDevelopers | ||
|
|
||
| manish: if we only have the sys crate, and you're the only one using it; people are going to build high level bindings around; I think it's good to have them together (both for developing and for having a finish product) | ||
|
|
||
| nico: on freetype Chromium is moving to fontation, maybe that could be useful for us | ||
| martin: we might still need freetype for some features or find some replacement | ||
|
|
||
| martin: we're looking into those things from Chromium and looking into use some of them when it makes sense | ||
|
|
||
| martin: I'm happy to give a try to maintain the sys crate, and add ICU folks to help with the high level one | ||
|
|
||
| nico: I think it's good to open maintenance to other contributors in particular crates | ||
|
|
||
| martin: we do have maintainers that are not really working on servo | ||
|
|
||
| ### Crates maintenance | ||
|
|
||
| rego: https://github.com/servo/project/blob/main/governance/tsc/tsc-2023-11-14.md#servo-crates-maintenance | ||
|
|
||
| rego: Like Martin mentioned there are many repositories. We have 52 repositories. we are not paying attention to them due to lack of time and priorities. We agreed that it would be nice to start look at some of these. One proposal is opening the maintenance to external people. | ||
|
|
||
| greg: It relates to the discussion we just had. We had some contribution from Jonathan on rust-freetype. It's not clear who is supposed to review changes. I realized I didn't have access to one of them. Another example is rust-url which seems to be informally maintained by someone from Gecko. Valentin. And also some issues are being tracked in the Gecko mozilla issue tracker. | ||
|
|
||
| greg: Maybe per-crate we could add maintainers and links to issue trackers. | ||
|
|
||
| manish: The issue tracker for rust-url is because they use it in Gecko. They track upstream and downstream bugs. I wouldn't move it to the Gecko tracker because we are upstream. | ||
|
|
||
| greg: What about adding some information about who the maintainers. | ||
|
|
||
| manish: We can still have servo members help out and maintain and help out with bug fixes. There are sometimes features requests, but that doesn't involve the TSC. | ||
|
|
||
| martin: there's a feature on github, the code owners file | ||
|
|
||
| nico: a lot of crates don't really have maintenance, but some of the crates have forks and things like that | ||
|
|
||
| martin: there are some types of crates we haven't talk about yet, one is ipc-channel, string cache | ||
|
|
||
| nico: string cache is used all over the place | ||
|
|
||
| martin: some of these have issues and it'd be great to have people that care about those helping out, or people from TSC helping to make them work well | ||
|
|
||
| martin: on the opposite side of the spectrum there are crates that are only used by servo and are maintained in separated repositories, sometimes we have to do a wave of complex dependency upgrades of our own software just because they're not in the servo repository | ||
|
|
||
| martin: maybe we can find more things we could move into the servo repository | ||
|
|
||
| martin: take a look to the bug about upgrading winit, which is only used by servoshell, and it involves tens of crates | ||
|
|
||
| nico: maybe we can group the repositories and check which ones are only used by servo, which ones are maintained by servo, etc. | ||
|
|
||
| nico: Maybe we could group crates by use, maintanance, etc. | ||
|
|
||
| gregory: There's a [Google Doc](https://docs.google.com/spreadsheets/d/1CNEPUytBMTZWUCZ1MgXPaMRuh6EIL10ykYabzw1fnME/edit?usp=sharing) in the issue. Maybe we can start working off of that. | ||
|
|
||
| ### AI generated PRs | ||
|
|
||
| martin: the reason we want to talk about this, it's related to the Outreachy contribution phase; we did receive some PRs that were generated by GitHub copilot or similar tools | ||
|
|
||
| martin: in general these PRs were complex to work with, sometimes the person that generated the code didn't really understand how it works, it made the review process very difficult | ||
|
|
||
| martin: other times the PR didn't do what it said, or did non-sense at some point; sometimes it removed sections of code | ||
|
|
||
| martin: from the perspective of reviewing this was a time sink | ||
|
|
||
| martin: maybe it's time to have a policy of what's the proper use of language models when contributing to servo; also because there're copyright issues | ||
|
|
||
| martin: so we'd like to discuss what kind of policy we can establish; even if it's just expectations for contributors | ||
|
|
||
| martin: at Igalia we had a conversation, and we want to propose a policy for this | ||
|
|
||
| martin: our proposal is: | ||
|
|
||
| martin: we think these tools are knowingly trained on copyrighted work, so their output is a liability for the project | ||
|
|
||
| martin: these tools make it too easy to generate large amounts of plausible but dangerously incorrect contributions, which we do not have the capacity for as maintainers | ||
|
|
||
| martin: we've based this ideas in the discussion in the [Gentoo mailing list](https://www.mail-archive.com/[email protected]/msg99042.html) | ||
|
|
||
| martin: our proposal is to disallow the use of generative AI tools when contributing to Servo projects, including code, documentation, and bug reports | ||
|
|
||
| nico: I don't personally use such tools, but I know they are popular. The argument that it would be more serious contributors off. It's clear that we don't want low effort entirely generated with AI. I think senior software engineers are starting to use these tools. I wouldn't oppose this policy, but... | ||
|
|
||
| gregory: I tried out GitHub Copilot if you are contributing to open source like Servo and it looks pretty well. I wrote a little Rust script a few days ago and it guesses what you're going to do, but it does make a lot of suggestions. If people are working with that and accepting suggestions and just opening a PR without having a look at it themselves. Even I was caught-on with something. I wanted to refactor something -- it uses an API that inserted and moved and only realized it later. What I'm trying to say is we could decide to ban it, but on the other hand there are also some opportunities -- for instance to generate bindings. On the DOM side of things it could be nice if it could generate some more boilerplate with AI. | ||
|
|
||
| gregory: We have patterns in the code, but GitHub Copilot is not able to recognize them. In the short term if it's experienced as spam, then you could have a temporary ban. With Stack Overflow they have done that. | ||
|
|
||
| rego: People can always use these tools and you may not notice that. If you have a nice editor that autocompletes, that's not a problem. It's these kind of PRs. If people are fine, maybe we can draft this proposal. | ||
|
|
||
| ### Crowdfunding | ||
|
|
||
| rego: We still have the LFX platform open. We are still talking to the LF to transfer the money to open collective. That hasn't happened yet, but OC and GitHub sponsors have a bunch now. In a month or so, 2500 collected. We can talk about how to use this money in the future. Just an update on the situation. | ||
|
|
||
| ### Outreach | ||
|
|
||
| rego: There is a GOSIM event happening in the Netherland in one week. Gregory will be talking about Servo there. Nico & Jonathan will Servo there. | ||
| gregory: It's next week. | ||
|
|
||
| rego: https://europe2024.gosim.org/ | ||
|
|
||
| rego: The next day is RustNL. Rakhi is also attending that one. There will be a bunch of Servo people around and Rust people. | ||
|
|
||
| rego: https://2024.rustnl.org/ | ||
|
|
||
| rego: In a month there is the Web Engines Hackfest in June. Nico and the Igalia team will be there. Registration is still open. | ||
|
|
||
| rego: https://webengineshackfest.org/ | ||
|
|
||
| ### AOB | ||
|
|
||
| nico: I was wondering if there was a plan to publish stylo now that it is caught up. | ||
|
|
||
| martin: one thing that would be nice before publishing would be to reduce the diff, which is the next step of the process, trying to push our changes upstream | ||
|
|
||
| nico: there might be gecko changes that have been not used by servo | ||
| martin: the majoritarian of those we don't have an implementation yet, maybe makes sense to have some configuration option to identify things that are being used by Servo | ||
|
|
||
| martin: maybe software that is not a webbrowser wants to get all features | ||
|
|
||
| nico: maybe get some prefs system | ||
|
|
||
| martin: or another build mode, we have probably to talk about this with emilio | ||
|
|
||
| emilio: fwiw I was trying to reply just now to that pref stuff... Not married to gecko static prefs, but they seem nicer than Servo's approach, so if we unify the API there it'd be nice | ||
|
|
||
| rego: thanks everyone, this is over | ||
|
|