Re: [dev-servo] Intent to vendor Servo in mozilla-central
On Wed, Jan 11, 2017 at 10:48 PM, Henri Sivonenwrote: > On Wed, Jan 11, 2017 at 3:04 PM, Ted Mielczarek > wrote: > > On Wed, Jan 11, 2017, at 06:03 AM, Henri Sivonen wrote: > >> Does that mean that crates under third_party/rust/ are going to have > >> their entire histories imported in the future? Currently, they only > >> have vendoring-time snapshots. > > > > I'm unaware of any plans to do this. I'd expect us to have a distinction > > between: > > 1) Crates where Mozilla is the primary author but the repository of > > record is somewhere else like GitHub (like Servo). > > (I'm writing a crate that I expect to be categorized like this in the > future, which is why I'm interested.) > > > These will probably > > be vendored specially into somewhere other than third_party/rust as > > Servo is. There are other non-Rust projects that want this as well, such > > as Azure (the graphics library) and devtools. > ... > > 3) Crates where Mozilla is not the primary author, pulled in as > > dependencies from crates.io. These will continue to be vendored into > > third_party/rust. Note that crates.io currently doesn't require crates > > to specify a VCS repository or revision or anything like that, so I'm > > not sure it's completely tractable to vendor these dependencies with > > full history anyway. > > Most crates currently under third_party/rust/ are already show at > least one Mozilla employee as a co-owner on crates.io (and, I'm > guessing, primary author), so at present, we've already used process > for category #3 for crates that arguably are category #1. > > I'm unconvinced that it makes sense to distinguish between category #1 > and category #3 in terms of placement in the m-c directory structure > on people org chart grounds. I can see a technical case for placing > history-imported and history-not-imported crates differently in the > m-c directory structure, though, but it's not immediately obvious (to > me) that people org chart situation should be the deciding factor in > whether it's worthwhile to import the history of a given crate. > Yeah, I think the actual distinction is that we're doing special work for servo (because we want to import history, and because we want to be able to commit to it directly in m-c), whereas the stuff in third_party/rust is what gets vendored automatically based on the crates.io dependency graph of Gecko's Cargo.toml. bholley > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [dev-servo] Intent to vendor Servo in mozilla-central
On Wed, Jan 11, 2017 at 3:04 PM, Ted Mielczarekwrote: > On Wed, Jan 11, 2017, at 06:03 AM, Henri Sivonen wrote: >> Does that mean that crates under third_party/rust/ are going to have >> their entire histories imported in the future? Currently, they only >> have vendoring-time snapshots. > > I'm unaware of any plans to do this. I'd expect us to have a distinction > between: > 1) Crates where Mozilla is the primary author but the repository of > record is somewhere else like GitHub (like Servo). (I'm writing a crate that I expect to be categorized like this in the future, which is why I'm interested.) > These will probably > be vendored specially into somewhere other than third_party/rust as > Servo is. There are other non-Rust projects that want this as well, such > as Azure (the graphics library) and devtools. ... > 3) Crates where Mozilla is not the primary author, pulled in as > dependencies from crates.io. These will continue to be vendored into > third_party/rust. Note that crates.io currently doesn't require crates > to specify a VCS repository or revision or anything like that, so I'm > not sure it's completely tractable to vendor these dependencies with > full history anyway. Most crates currently under third_party/rust/ are already show at least one Mozilla employee as a co-owner on crates.io (and, I'm guessing, primary author), so at present, we've already used process for category #3 for crates that arguably are category #1. I'm unconvinced that it makes sense to distinguish between category #1 and category #3 in terms of placement in the m-c directory structure on people org chart grounds. I can see a technical case for placing history-imported and history-not-imported crates differently in the m-c directory structure, though, but it's not immediately obvious (to me) that people org chart situation should be the deciding factor in whether it's worthwhile to import the history of a given crate. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [dev-servo] Intent to vendor Servo in mozilla-central
On Wed, Jan 11, 2017, at 06:03 AM, Henri Sivonen wrote: > Does that mean that crates under third_party/rust/ are going to have > their entire histories imported in the future? Currently, they only > have vendoring-time snapshots. I'm unaware of any plans to do this. I'd expect us to have a distinction between: 1) Crates where Mozilla is the primary author but the repository of record is somewhere else like GitHub (like Servo). These will probably be vendored specially into somewhere other than third_party/rust as Servo is. There are other non-Rust projects that want this as well, such as Azure (the graphics library) and devtools. 2) Crates whose repository of record is mozilla-central. This is likely to be primarily Gecko glue code, like the nsstring[1] crate. 3) Crates where Mozilla is not the primary author, pulled in as dependencies from crates.io. These will continue to be vendored into third_party/rust. Note that crates.io currently doesn't require crates to specify a VCS repository or revision or anything like that, so I'm not sure it's completely tractable to vendor these dependencies with full history anyway. RE: your other point, we have a few bugs around verifying licensing on vendored crates, as well as implementing some sort of "trust checking" to verify what we're pulling in from crates.io: https://bugzilla.mozilla.org/show_bug.cgi?id=1316990 https://bugzilla.mozilla.org/show_bug.cgi?id=1322798 -Ted 1. https://dxr.mozilla.org/mozilla-central/source/xpcom/rust/nsstring ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [dev-servo] Intent to vendor Servo in mozilla-central
On Wed, Jan 4, 2017 at 1:35 AM, Gregory Szorcwrote: > Also, I anticipate the techniques and tools used to import Servo's history > and keep it "synchronized" have uses outside of Servo. Our current > mechanisms for keeping upstream/third party projects in sync with > mozilla-central are not well standardized. I'd really like the work to > support Servo to be used for other projects as well. This potentially > includes a future where certain directories in mozilla-central are > effectively developed on GitHub or are using other "non-standard" > workflows. Does that mean that crates under third_party/rust/ are going to have their entire histories imported in the future? Currently, they only have vendoring-time snapshots. If so: 1) Will the history before import likewise be hidden from bisect? 2) How are we going to review the history of genuinely third-party crates for stuff we shouldn't host? E.g. are we going to do licensing review on the past revisions of an imported crate in addition to vetting its current state? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform