I think one important aspect here is to separate out the concerns of vendoring code in-tree vs where that code is developed. It sounds like Gecko has lots of technical requirements about why and how code lives in-tree, but the more important bit here is how it changes over time.
What Yehuda was saying about how forking or syncing having downsides I think is quite important for Rust code in Gecko, as this may run the risk of splitting the ecosystem on various boundaries (e.g. the "gecko rust-url" and the "upstream rust-url" or something like that). Along those lines I think it's very important to drill down into exactly what concerns there are about having these components developed in the Servo-style as they are today. It sounds like there's some hesitation about this today, but Yehuda I think is making a good case that tooling can make the process quite easy. There's quite a lot to benefit from with having only "one source of truth" for all this code! On Mon, Dec 21, 2015 at 2:45 PM, Yehuda Katz <wyc...@gmail.com> wrote: > Yehuda Katz > (ph) 718.877.1325 > > On Mon, Dec 21, 2015 at 2:28 PM, Josh Matthews <j...@joshmatthews.net> > wrote: > >> On 2015-12-21 5:21 PM, Yehuda Katz wrote: >> >>> On Mon, Dec 21, 2015 at 2:14 PM, Bobby Holley <bobbyhol...@gmail.com> >>> wrote: >>> >>> I don't think this is going to fly in Gecko, unfortunately. >>>> >>>> Gecko is a monolithic repo, and everything needs to be vendored in-tree >>>> (a >>>> non-negotiable requirement from the build peers). This means that we'll >>>> already need an automated process for pulling in updates to the shared >>>> code, committing them, and running them through CI. >>>> >>>> >>> Can you say a bit more about what the requirements are here? Is the reason >>> for including the code in-tree that you need to be 100% confident that >>> everyone is talking about the same code? Or is it more than that? >>> >>> >> The "non-negotiable requirement from the build peers" is that the machines >> that build Firefox do not have internet access. > > > That's a totally reasonable requirement and one that I am very comfortable > saying that Cargo should support. > > To support this requirement, we plan to add a new command that packages up > an application into a single tarball (or equivalent), complete with all > dependencies, and another command that can build such a package without > network connectivity. > > Bundler has equivalent facilities (bundle package and bundle install > --deployment) that I consider indispensable for deployment scenarios, and > which I championed early on in the bundler process. (Heroku uses `bundle > install --deployment` in their buildpacks). > > -- Yehuda _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
