Tarballs, tarballs everywhere (or "More madness of glibc")

My previous posting on the packaging of GNU's glibc project seems to have created quite a stir (see here and here). There's been lots of informed, and some uninformed, debate on the subject.

The glibc project has taken the informed choice to abandon the traditional tarball method of source code release, instead directing developers to get the code from the project's CVS repository directly. Thankfully, following my earlier post, instructions have been put up on the public website so it's now clearer how to obtain the latest version of the glibc source from CVS. So my initial problem has now been solved. Thanks, guys!

Now, clearly this isn't the End Of The World. And any developer capable of working usefully with glibc should be more than competent enough to operate CVS themselves. So stop whinging and get over it... right?

Wrong.

The madness of CVS

Source code projects should always be developed using a Source Code Management system, like CVS (or Subversion, or perhaps a more modern, fashionable, distributed SCM like Bazaar). This is common sense. It's good practice. It's important. Each release should be managed in the SCM on a release branch, and public code drops should be recorded with tags (or labels). This is accepted release engineering practice.

However, downloading a source code release from CVS (or any other SCM) is a really poor distribution mechanism. Here's why:

• It's not conventional. Unix source packages are traditionally distributed as tarballs (either tar.gz or tar.bz2 tarballs). It's the way the world works. Not providing tarballs forces users to work harder, and makes them less likely to use your code. However, this is not a compelling reason for glibc to distribute tarballs. Indeed, for glibc it's not even an issue. The project is important enough that people will do whatever is necessary to get the source. The glibc developers can distribute their code however they like. And I'll always say thank you.
  
• It's not secure. Downloads sometimes go wrong. Unusual, but it can happen. Servers can also be hacked, and the code fiddled with. The accepted convention for this is to distribute MD5 checksums of the source tarballs that the downloader can use to ensure that their tarball is indeed the original. It's far easier to do this on a tarball than a CVS checkout (and there is currently no check mechanism for CVS exports from glibc). This is important, but is also not a compelling reason for glibc to distribute tarballs.
• It's failable. By definition, the code in an SCM is dynamic. It changes over time. The codeline in the release branch changes as the release nears completion. True, the 2.7 relelase, and the 2.8 release and the 2.8.1 release can be individually tagged. However, these tags are dynamic. There is no guarantee that at a point some time after the 2.7 release, someone can't go back to the CVS repository and move the 2.7 release tag. The glibc 2.7 release could be different on Tuesday that it was on Monday! Sure, good developers shouldn't do that. But they might. By mistake or otherwise. In less capable SCM systems, like CVS, there is no way of usefully tracking the history of the tag. Release tags in CVS are not static. The only safe way to construct a stable, unchanging release snapshot of the code is to archive a tarball. Say, on an FTP site. This is a compelling reason not to download glibc source code releases from the project's CVS repository.
  

I believe that CVS access is simply not an acceptable release mechanism for the glibc, or for any other, project.

There has to be another way

Additionally, people have been pointing out third party ways to get glibc more easily, or to track its progress more easily, like an external gitweb interface. This is also not an acceptable solution for easily pulling glibc releases. As a developer who would like to use pure, unadulterated glibc source code release, I can only accept source code that I obtain directly from the glibc project themselves.

I know these third parties are trying to perform a useful service, and are doing this with the best intentions. But, unfortunately, I can only accept source code drops that come directly form the official project. Not from unverifiable third party mirrors, or from tarballs packaged by a third party (like Fedora - how can I be sure that over time they won't put their own Fedora-specific patches in their version of glibc?)

If these are useful services, the providers should join the hard working glibc team, and perform their packaging services under their umbrella as an official service.

Postscript

I have nothing against the glib developers, or the glibc project itself. I appreciate all of their hard work. I offer this as constructive feedback. And I particularly do not like personal abuse directed at individual people. They are all hard working, clever guys who benefit the community greatly. I hope that I give back to the community a fraction of what they have done!