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
