servo
Servo TSC Meeting September 2024
- Date: Monday 23rd September 2024 at 15:00 UTC
- Location: https://meet.jit.si/Servo-TSC
Agenda
- Status update
- SVG images support
- License approval of two small non-MPL2 crates
- Using TLA+ to model concurrent algorithms
- CI runners status
- Crowdfunding
- Website revamp
- Ideas: made width page, partnership page
- Outreach
- AOB
Another idea for discussion could be SVG images support to discuss the different approaches and what would be a good plan.
Example, using a third-party library implies we have code duplicated doing similar things, but maybe that can be done "quickly". While having full SVG support is a too big project, but maybe some initial SVG rendering is possible.
It'd be nice to have an idea of the different approaches and how easy/complex they'd be to develop, in order to try to have a plan for this.
I'd like to propose an agenda item about license approval of two small non-MPL2 crates/repos under github.com/servo/:
I'm in the process of implementing the suggestion stated in https://github.com/servo/rust-url/issues/939#issuecomment-2223650466 and it is my understanding that non-MPL2 licenses under the Servo GitHub org require an OK from the Servo TSC. Hence:
idna_adapter: "Apache-2.0 OR MIT"
I intend to introduce an idna_adapter crate and repo declaring "Apache-2.0 OR MIT" as the license. Non-MPL2 rationale: This factors code out of the idna crate, which is already under this dual license.
I'm hoping to move https://github.com/hsivonen/idna_adapter/ to https://github.com/servo/idna_adapter/ and to make the idna crate depend on it.
idna_mapping: "(Apache-2.0 OR MIT) AND Unicode-3.0"
I intend to introduce an idna_mapping crate and repo declaring "(Apache-2.0 OR MIT) AND Unicode-3.0" as the license. Non-MPL2 rationale: This factors code out of the idna crate as it existed at version 0.5, and while idna 0.5 only declared the MIT OR Apache-2.0 dual license in crate metadata, it actually contained data transformed from IdnaMappingTable.txt provided by the Unicode Consortium. I believe https://www.unicode.org/terms_of_use.html means that the data (at least from version 15.1 onwards; I don't intend to use older data than that) is subject to Unicode-3.0, and I believe the transformation should retain that license.
That is, this is about correcting the licensing metadata to properly reflect the presence of Unicode data and Unicode data was already in a Servo-hosted crate. Unicode-3.0 is an OSI-approved MIT-like license. I believe the above SPDX expression is correct, since the downstream recipient needs to comply with Unicode-3.0 in addition to complying with either Apache-2.0 or MIT.
I'm hoping to move https://github.com/hsivonen/idna_mapping/ to https://github.com/servo/idna_mapping/ and to make one version stream of idna_adapter depend on it.
Users of the idna crate would not end up using the idna_mapping crate by default. In would be opt-in. By default, they'd end up using icu_normalizer (which is under Unicode-3.0).
Is the above OK?
Please add to the agenda:
- quick mention of using TLA+ to model concurrent algorithms in Servo(blog post with example).
Selectors Release
Work to prepare the selectors crate has landed upstream. It should now just be a case of running cargo publish for servo_arc, to_shmem and selectors (although extra review is always welcome), but we need someone with the requisite permissions to press the button.
EDIT: We possibly ought to update the repository links in the Cargo.toml files (although this could easily be done in a patch release).
CI runners status
We’ve set up a server to host faster CI runners for 104 EUR/month, though this is expected to increase to 125.84 EUR/month for VAT reasons. After some initial iterations, the server is now running smoothly.
To make the most of its capacity, which is limited compared to the combined capacity of 60 GitHub-hosted runners, we use it for the Windows and Linux build jobs. Windows builds were over an hour before, now they’re under 18 minutes. Linux builds were over half an hour, now they’re under 8 minutes.
As a result, full WPT try runs should now be around 20 minutes faster. Further work is being done to self-host our macOS build jobs, which are now the bottleneck.
