Thanks for doing this investigation, Valentin! I'm a little bit worried about the mechanics of auto-upstreaming: - How do we handle commit access? Having the upstream maintainers (none of whom might be current Gecko peers) correctly identified and doing reviews in bugzilla to ensure m-c pushes can be upstreamed seems challenging. - What about conflicts? If even half of Servo's dependency graph is pulled in, that will be ~30 different repos, and the odds that some of them will temporarily be incompatible with others means that a m-c commit may be against an older version of upstream and not able to be automatically upstreamed into master. Does everything vendored in m-c get a private fork in the mozilla GH organization and get code and policy conflicts resolved there? - As I've heard it from the cargo team, this approach is different from the solutions being pursued by the other nontrivial (>= 5 million LOC) corporate build systems. I worry a bit about having a different tool stack than the rest of the ecosystem and potentially confusing volunteers who would like to contribute to Rust code in Gecko or have their projects used in Gecko.
That said, trying to figure out how to make the obvious extension of the current experience (set a `paths` override in a config file, clone the repo, do the work there, open a PR and land upstream and push to crates.io, remove the override, run the "vendor into m-c" tool to pull it down, and *finally* land in m-c) seems brutal even for a single dependency, much less something that sweeps across several of them. The answer to any approach we come up with is probably "more tooling," but I suspect that, like bholley said below, there's a lot of discussion to be had here around the myriad issues. This conversation is also going on in Bugzilla here: https://bugzilla.mozilla.org/show_bug.cgi?id=1231764 and also has build peers and Cargo folks in the discussion. I believe they're not on dev-servo. - Lars On Thu, Dec 17, 2015 at 5:28 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: > I had a long conversation about the two-way sync stuff at Orlando with Alex > and some of the Servo folks. > > We concluded that, long-term, we need to let Gecko hackers commit to the > vendored code and have that code automatically upstreamed. Similarly, > upstream fixes need to be automatically merged into Gecko. > > Everyone seemed on board with this plan, but Alex suggested that it should > probably be a separate tool, distinct from Cargo. This tooling is going to > be pretty important, but we should probably wait on it until we've got the > other issues sorted out. > > bholley > > On Thu, Dec 17, 2015 at 3:04 PM, Valentin Gosu <valentin.g...@gmail.com> > wrote: > >> Hi folks, >> >> I just wanted to share some notes on using Cargo in Gecko. One of the >> requirements was vendoring packages in tree. It turns out I was able to do >> that with a .cargo/config file in the scope of the rust directory, which >> defines the paths for dependencies, and [http] timeout = 0, which prevents >> downloading any resources from crates.io. [1] >> Better support for this use case would be welcome, such as making sure no >> network connections are made (the index still gets refreshed), but this is >> good enough for what we need at the moment. >> >> I'm not sure if we've agreed to have a top level directory for all of the >> rust crates, but I think it makes sense. It allows for easier sharing of >> crates (between necko and media for example). >> From what I understand servo's mach has a command for two-way sync between >> web-platform-tests and upstream. This would be a nice feature for cargo, as >> most of our dependencies would come from crates.io. So identifying the >> upstream repo, and doing a diff would be super awesome - probably for other >> projects as well. >> >> I'll probably have more to share once/if I manage to use cargo withing >> Gecko's build system. >> >> Thanks! >> >> [1] https://github.com/rust-lang/cargo/issues/1926 >> _______________________________________________ >> dev-servo mailing list >> dev-servo@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-servo >> > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
