> The API is probably fine, but there will be a *ton* of coordinated changes > across Firefox/WR here. Shader tuning, implementation bug fixing, etc. None > of these changes will be tested by the autolander in the context of Firefox > if WR is a separate repo, so they will have to get "bounced" at the time that > WR is updated in servo/servo, at which point you then have to pull them > around the crates.io loop again.
I guess what I mean is why can't the same mechanism be used? For example, servo/servo, servo/webrender, and servo/webrender traits all already share CI. Why not just do the same mirroring we're proposing to all three repos? Where does rust-layers fit into all this? Do we change it much? Are we getting rid of it when webrender is the default? If we start consolidating things that are already factored out, aren't we going to end up with a servo monorepo? Ie, won't rust-cssparser and rust-stylesheets be close behind for moving underneath servo/servo? What is the criteria for things being in servo/servo under this new plan? It sounds like the current proposal is to move everything we control into servo/servo when that thing is needed by Gecko. The old plan was everything was separate to the extent practical. > 2) that's why I proposed getting it on crates.io :-) I'd certainly hope & > expect there to be other consumers downstream. What's the use case for a non-browser consumer? jack. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
