This seems like a good idea. Please consider adding hg.mozilla.org to your list of things you will clone from. That will allow us to remove some ugly hacks from the tree for vendoring NSS and NSPR. (libffi uses the same script, but it seems to be on GitHub now, so that seems like an easy win assuming even that libffi still uses that script.) We could use the NSS GitHub mirror, but NSPR doesn't have one yet and those can't be the only projects that we have using mercurial. Of course, if that is the case, then don't worry, we'll just have to talk more seriously about moving NSS to GitHub.
You don't permit the use of a tag for vendoring, is that intentional? Tags for releases are so commonplace that you should consider it. You shouldn't need a branch AND a tag either. More so because branches move, which makes them not reliable here. Having a version in addition to a tag is redundant and therefore likely to result in mismatches. I'd say that the tag is enough. (FWIW, NSS does some of its own vendoring for test runs, so maybe you could look at https://searchfox.org/nss/source/fuzz/config/git-copy.sh - vendoring git repos without pulling history turned out to have a few gotchas.) On Tue, Apr 10, 2018 at 2:25 PM, glob <g...@mozilla.com> wrote: > mozilla-central contains code vendored from external sources. Currently > there is no standard way to document and update this code. In order to > facilitate automation around auditing, vendoring, and linting we intend to > require all vendored code to be annotated with an in-tree YAML file, and for > the vendoring process to be standardised and automated. > > > The plan is to create a YAML file for each library containing metadata such > as the homepage url, vendored version, bugzilla component, etc. See > https://goo.gl/QZyz4x for the full specification. > > > We will work with teams to add moz.yaml files where required, as well as > adding the capability for push-button vendoring of new revisions. > > > Please address comments to the dev-platform list. > > -- > glob — engineering workflow — moz://a > > > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
