Dropping bzip2 release tarballs?

[Ben Gamari]

David Feuer <david.feuer at gmail.com> writes:

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160202/5b8cbb5a/attachment.sig>