> Your proposal scares me in the sense that (if I read it well) it would > be at least temporarily allowing changing the style system without > gating on Servo. There are architectural changes to the style system > that work for Gecko, but would completely break Servo.
> Right now landing a change like this means being sure you're able to > generalize enough so it works for both layout systems. If we don't gate > on Servo, this phase would get postponed, and I think that's extremely > dangerous. As Jack said, this will still be a factor in the review process. AIUI we can pull in things from Github in try builds, and we can have a non-gating servo build that is only run on try. Most such architectural changes will go through this. (We can have a hash-pinning system if we need) Note that I'm proposing keeping most of ports/geckolib in the new style repo too. > I agree that there are challenges with mirroring the root Servo > repository into m-c, but I'd like to make sure we mention some of the > positives that we get from it Oh, yes. I'm not sure if this was clear already, but as someone who will be spending most of his time on stylo for the forseeable future, vendoring servo in-tree is the best solution as far as my personal workflow is concerned. But I'm trying to look for alternatives that work for everyone, since there's a lot of backlash on the testing thing. Good point on gecko-giving-back-to-servo. > After some brainstorming, one idea that came up is that we could leave > the tests in the servo repository, but in the mirrored copy in m-c, I like this idea. We could just vendor the metadata in tree (but not the tests) to fix the expectations issue. Feels hacky though, and might lead to something getting lost accidentally. > And I think that having a "you should also have a Servo PR > open" ideal is not going to fly. You might as well rename Servo to > ThunderServo :-) Even if everybody comes into this with the best > intentions, we do not have the tooling, process, or culture to support > that kind of workflow on a highly unstable module like that. Yeah, that makes sense. You're right, comm-central had a model with similar drawbacks, and that didn't work well. ------------------------- It seems like there's general agreement that vendoring servo in-tree is better than this model? I think in that case we should probably brainstorm a bit about making it easier for Servo contributors to contribute to m-c. While the current model still keeps it easy for people to contribute to Servo, it seems like in the future Servo will be more closely tied to Gecko and working through m-c might become more common. Preparing for that would be nice, and there's plenty of time to do so. This may involve tweaking m-c's model and/or tooling (e.g. allowing PRs to gecko-dev, which hook into mozreview instead of getting directly merged on gh, or making mozreview work with non-cinnabar clones of gecko-dev). I'm also planning to dip my toes in mentoring Firefox/Gecko bugs again, and see what the new contributor experience is like now and how it can be improved. I already have rough ideas for this (and a general sense of where the problems are), but that's getting a bit off-topic for this thread. Thanks, -Manish _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
