Re: gnome-1.4.1 beta1

[Laszlo PETER <Laszlo Peter ireland sun com>]

Darin Adler wrote:
> 
> On Tuesday, July 31, 2001, at 10:22  AM, Laszlo PETER wrote:
> 
> > Neither is xml-i18n-tools-0.8.4...
> 
> I reverse-engineered a tag for xml-i18n-tools 0.8.4 that exactly matches
> the contents of the tarball.

Thanks.

> > It would be nice to be able to build the whole thing from CVS.
> 
> I don't always trust that a tag in CVS with the same name as the release
> tarball is *exactly* the same as what's in the tarball. Try doing some
> diffs and you'll see that people don't always do that right.
> 
> I personally think that getting releases from CVS is not a good idea.

I've got a good reason for releasing from CVS. If you keep building regular
builds from CVS HEAD, test them, do your development/bug fixes agains them, 
then it's more dangerous to change to tarballs a few weeks before the
binary release.
I've tried it with GNOME 1.4 and it was a real pain.
Some problems I saw:
 - tarballs contain lots of generated files -> the build env of the maintainer
   will affect your release
    - different versions of libtool, autoconf, etc. will be used not your
      fine tuned build evironment
    - generated HTML docs using different stylesheets
 - local patches that modify configure.in or Makefile.am will fail.
   (No new features, forking, etc! just build/default configuration
   stuff and maybe bug fixes that didn't make it into the release.
   So no conspiracy theories, please.)
 - files missing from tarballs
 - dead symlinks (to install-sh & friends)

At the end of the day, it matters less if your code is slightly different
from the "official release".

So is there a reason why maintainers can't do The Right Thing when releasing
a tarball?

Laca