David Feuer
Does this really strain storage infrastructure? There are only a few blobs per release.
To me the real motivation here is to simplify the distribution preparation process. Currently I need to worry about producing, signing, hashing, and uploading two of each tarball. To do this requires a dozen or so lines of bash source that I'd prefer not to have to maintain. It's not the end of the world While our release process is improving, it's unfortunately still a bit finicky. Requirements like having to produce redundant tarballs don't help. I wouldn't say that our storage infrastructure is particularly strained. However, it is a finite resource and if we can use less of it per release at no cost then I think we should.
If that's really a problem, sufficiently ancient ones can presumably be pruned down to a single format without too many complaints (e.g., if someone wants GHC 7.6, they may not be able to have their choice of format).
I would not feel comfortable doing this for any release in 7.0 series. Once we put up a distribution, users should be able to expect that it will be there for the foreseeable future.
Bandwidth seems an entirely legitimate concern, but thankfully a symmetric one—most users will want to download the smallest available format, and those who are willing to pay the extra time to download another likely have a good reason.
This is essentially the point I'm trying to make: it appears that essentially everyone uses the xz distributions. If this really is the case, then I would ask why are we spending the disk space, effort, bandwidth, and complexity preparing the bzips. I can't think of a reason why users would prefer bz2 over xz but that of course does not mean that one does not exist. This was the reason for this thread. So far I get the impression that the bzip tarballs will not be missed. Cheers, - Ben