On Mon, Feb 27, 2017, at 12:32 PM, Henri Sivonen wrote: > On Mon, Feb 27, 2017 at 7:04 PM, Ralph Giles <gi...@mozilla.com> wrote: > > On Mon, Feb 27, 2017 at 4:03 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > > > >> I find this level of difficulty (self-inflicted quasi-Tivoization > >> practically) an unreasonable impediment to practicing trivial Software > >> Freedom with respect to the vendored crates. > > > > I agree we need to fix the ergonomics here, but I don't think you > > should be so hard on cargo. > > Sorry about the tone. I'm rather frustrated at how hard it is to do > something that should be absolutely trivial (adding a local diagnostic > panic!()/println!()). > > > The hash checking is designed to make > > builds more reproducible, so that unless we make an explicit diversion > > we know we're building with the same source as every other use of that > > same package version. This has benefits for security, debugging, and > > change control. > > We don't seem to need such change control beyond hg logs for e.g. the > in-tree ICU or Skia, though.
As someone who has maintained a vendored upstream C++ project (Breakpad) for a decade, I can say that this causes us headaches *all the time*. We are constantly landing local changes to vendored projects and not keeping track of them and then either losing patches or dealing with conflicts or breakage when we update from upstream. I'm sorry this is causing you pain, and we should figure out a way to make it less painful, but note that the intention is that things in `third_party/rust` should be actual third-party code, not things under active development by Mozilla. We don't currently have a great middle ground between "mozilla-central is the repository of record for this crate" and "this crate is vendored from crates.io". We're finding our way there with Servo, so we might have a better story for things like encoding-rs when we get that working well. I understand that there are lots of benefits to developing a crate in a standalone GitHub repository, and you're certainly not the only one who wants to do that, but it does make the integration story harder. It's very hard to support code that has its repository of record somewhere other than mozilla-central, but also have a simple workflow for making changes to that code in mozilla-central along with other code. -Ted _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
