> On Jun 20, 2016, at 10:16 AM, Jack Moffitt <j...@metajack.im> wrote: > >> 2) Move webrender and webrender_traits back into the Servo repository. > > WebRender has a small and stable API. This API didn't even need to > change in WebRender 2 from my understanding. This means we'll be > moving a very low coupling dependency into servo whereas in the past > we have pushed to move these out. > > Why does the plan require this be moved into Servo? The autolander > setup is the same, and it would seem we could just replicate the same > setup as is being proposed for servo/servo.
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. Maybe we can make this easier by having people do `try` runs where they use a cargo.toml [[replace]] block and point at a git repo where they have pushed the commits for their WR changes before people open the PR in WR? I'm certainly open to this if we think we can make it still a good experience for Gecko devs. > Here are some questions around this that I think are worth answering > before deciding: > > 1) If we go down this path, when do we propose to do it? Once > WebRender 2 is landed? Landed and default? Now? > 2) Do we expect WebRender 2 to have any downstream other than our (or > other) browser engines? > 3) How will this affect development velocity? For example, will we now > have to wait for full servo builds to do testing? As I recall this is > the main reason it is separated in the first place. > 4) What does the alternative look like? In the meetings and documents > I was in, we focused heavily on the servo/servo case, and the other > dependency cases where not discussed as much. I assume those will be > handled by something better than what we are doing now; do we know > what that looks like yet? 1) I'd propose to do the merge once WR is on stable, published to crates.io (and thus reusable), and we have a final plan that we're executing on for sharing CI infrastructure with Firefox. 2) that's why I proposed getting it on crates.io :-) I'd certainly hope & expect there to be other consumers downstream. 3) yeah, changes will have to sit in the servo/servo queue. That said, I'm assuming people doing WR development have to do all of their testing on all platforms themselves, as there is no autolander support right now for ensuring that WR changes have not broken Servo on one platform or another. 4) The gdoc linked earlier has an overview of the workflow in that case. For the wider set of crates (which, for stylo, would include things like rust-cssparser and rust-selectors), you have to go through the normal Cargo/crates.io workflow of creating a fork, cloning it, creating a branch, opening a PR, etc. We may try to create some support in the monorepo for editing the vendored version of this code and automatically pushing it to a branch on a mozilla fork of the upstream repository, but such an action will still require manual (sheriff?) intervention to create and land a PR and eventually pull down the "final" change from the upstream repo once it has been rebased and merged. This part of the story is definitely the fuzziest and under the most active work. Thanks for the feedback / questions! Exactly what I was looking for :-) - Lars _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
