[PATCH] D70460: export.sh: Fetch sources from GitHub instead of SVN

[Hans Wennborg via Phabricator via llvm-commits]

hans added inline comments.


================
Comment at: llvm/utils/release/export.sh:53
+
+    for proj in $projects; do
+        echo "Creating tarball for $proj ..."
----------------
mgorny wrote:
> tstellar wrote:
> > mgorny wrote:
> > > hans wrote:
> > > > sylvestre.ledru wrote:
> > > > > tstellar wrote:
> > > > > > hans wrote:
> > > > > > > When I was thinking about this, I figured maybe we should just ship llvm-project.tar.xz and test-suite.tar.xz, rather than split up into the old project structure?
> > > > > > > 
> > > > > > > It seems odd in a way to release in a format that doesn't match the code layout used by developers. Do you think the llvm-projects.tar.xz tarball would be prohibitively large? Or that the change is too large for users of the release?
> > > > > > If we distributed a single tarball, that would be easy, because GitHub creates one for us and adds it to the list of release assets.  The gz compressed file generated by GitHub is 108M. 
> > > > > > 
> > > > > > However, as a distro packager, I prefer having the separate tarballs because that's what we use for building packages on Fedora and RHEL.
> > > > > > 
> > > > > > @mgorny, @sylvestre.ledru  Do you have any thoughts about this?
> > > > > For Debian & Ubuntu, I moved to a single tarball containing it all. Splitting tarballs doesn't bring much values compare to the maintenance cost.
> > > > > 
> > > > > BTW, using xz, the tarball is only 72M for 9.0.0
> > > > > 
> > > > I see.
> > > > 
> > > > I don't have strong opinions about this, but I always assumed that the non-monorepo layout build would go away at some point after the migration.
> > > > 
> > > > Maybe we should release both an llvm-project.tgz "monorepo tarball" and the separate ones for a while?
> > > I would prefer split tarballs. There is still a vast number of Gentoo systems whose users interface with LLVM only through Mesa dependencies, and they only need the main LLVM component (and no clang, in the more common case).
> > If we want to release an llvm-project tarball, should we have this script generate one or just go with what GitHub gives us[1]
> > 
> > Pros of relying on GitHub is it's easier and then we avoid having 2 source tarballs on the GitHub releases page (you can't remove the GitHub generated one).  Cons of GitHub is that it uses .tar.gz, so it's bigger than an xz compressed file.  108M vs 72M.
> > 
> > 
> > [1] https://github.com/llvm/llvm-project/releases/tag/llvmorg-8.0.1 (The "Source Code" links)
> Don't forget that git archive tarballs are not guaranteed to be stable. Their checksums occasionally change (when GitHub upgrades git, I think) and break everything relying on them.
Non-stable tarballs doesn't sound so good.

Another con of GitHub's is that I guess we can't sign them. Or if we do, and the GitHub one changes, the signature won't match.

I would prefer us uploading .tar.xz's and .sig's both for the separate projects, and one for llvm-project.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70460/new/

https://reviews.llvm.org/D70460