To be clear, I support the continued presence of rust-selectors on crates.io. My proposal here applies only to the canonical repository from which the publish happens - regular consumers of rust-selectors would not notice a difference. Anyone _contributing_ to rust-selectors would need to write a PR against servo/servo instead of servo/rust-selectors, which means their change would run against servo's CI (which is probably a good thing).
So far, the guiding principle for crate modularity has been "if there is a non-Servo consumer of the crate, publish it on crates.io and split the code into a separate repository". I think the first part of this is great. I think we have gone slightly too far on the second, specifically in the case of rust-selectors. Giving crates a dedicated repository reduces friction for non-Servo contributors, which is a good thing. But it can also add a lot of friction for Servo contributors, which is not good. There's an inherent tradeoff, and while I generally support a bias towards being contributor-friendly, I think there are some cases where the tradeoff doesn't make sense. rust-selectors was split out into a separate crate and repository in 2015. Since then, there has been one push (with 2 commits) by a contributor that does not also contribute to servo [1]. In that time, there have also been 268 other commits by Servo contributors, and 39 crate publishes, each of which requires futzing around with Cargo dependencies, and many of which require extra coordination for breaking changes. Here's a run-of-the-mill story of how this costs us: This past weekend, I decided to quickly hack up a fix to an architectural issue we have with selector matching and DOM mutations. I normally avoid fixing bugs that require touching rust-selectors (for the reasons described below), but since I was working on the special stylo incubator repository (which happens to have a vendored copy of rust-selectors), I decided to try it. The development experience was great: I was able to iterate easily on my changes, including multiple interdependent changes to servo and rust-selectors across several iterations of code review. I was also able to perform try pushes (on stylo builds) with a single command. But now I'm ready to land these changes, and things get tricky. The latest version of rust-selectors is several breaking versions ahead of the one used by servo, so now I need to either do these updates for code changes I'm not familiar with, or block my patch indefinitely until someone else does it: I can't make progress until that "lock" is released. And then I still want to run my combined (servo+rust-selectors) changes through servo try before landing and publishing the rust-selectors change, which means that I need to go push a special branch, and fuss with with the cargo manifests to reference the temporary branch, and then push that to servo/servo, and then trigger a try push, and then open a PR on rust-selectors, and then land it there, and then publish to crates.io, and then land my servo PR. This is super painful, and a large disincentive for me to make rust-selectors better - instead, it incentives me to hack around issues at the callsites whenever possible. I don't think that's a good thing. bholley [1] https://github.com/servo/rust-selectors/graphs/contributors , see marvelm _______________________________________________ dev-servo mailing list [email protected] https://lists.mozilla.org/listinfo/dev-servo
