For Xen, it's historical reasons funneled into "don't break things for your users". In the olden times, Xen had our own fork of QEMU, as well as our own fork o

For Xen, it's historical reasons funneled into "don't break things for your users". In the olden times, Xen had our own fork of QEMU, as well as our own fork of Linux, and some other useful tools like pvgrub. These were developed in a separate repository, but it was imported into the main Xen release tarball, so that you could just download the main tarball, do "./configure && make && make install" and have a reasonably complete Xen system. These days most Linux kernels can do everything we need, and our release tag of QEMU might only be one or two patches not yet in the upstream branch; and in any case, you can always use the most upstream release. So this isn't necessary anymore (and indeed we only include QEMU in the release tarball, not Linux or pvgrub). And you can still "./configure && make && make install" to get a fairly complete system, it will just clone other repositories on your behalf. On the other hand, I actually checked just last month, and the tarball for Xen 4.18.0, released back in November, was getting 700 downloads a week. Who are all these people downloading the release tarball, rather than using the distro version of Xen? Do they want and need these extra bits inside? We don't know and were hesitant to make any breaking changes. I think with the xz fiasco, we now have justification to switch entirely to a `git archive` tarball of a specific tag, whether it's inconvenient for people or not.