Reposting this without the extraneous mailing lists. Please reply to this one.
On Tue, Dec 22, 2015 at 9:23 AM, Bobby Holley <bobbyhol...@gmail.com> wrote: > On Mon, Dec 21, 2015 at 2:47 PM, Alex Crichton <acrich...@mozilla.com> > wrote: > >> 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. >> > > IME "Servo-style today" would already be an enormous hassle if it weren't > for the mitigating factor that most of the core browser components already > live in a monolithic repo. In the cases where some more core-ish code lives > in an external repo (like rust-selectors), making cross-coupled changes is > a huge pain, even with super-responsive maintainers like Simon. > > Given that I hack on both, I am interested in solving this problem for > Servo too. :-) > > >> 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 >> > > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
