Re: gnome-1.4.1 beta1

[Colm Smyth <Colm Smyth Sun COM>]

Laca,

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

Warning: "obvious" statement follows...

It might be easier if tarballs were created directly from CVS as
the CVS tree (mostly) does not contain generated files. People
have to "do the right thing" to put their files in CVS, why
not use it?

Maybe if we had a script that automated tarball creation
using CVS, people would be more inclined to do it this way.

Something like:

usage: cvsball <module> <cvs-tag>
creates a gzipped tar archive (aka tarball) of a CVS module using
the cvs-tag to identify file versions.

notes:
* uses $TMPDIR as working disk space while getting the files from CVS
* standard CVS environment variables apply

Of course if 'make clean' worked, commits to CVS would be easier
(and people with CVS-aversion could still make portable tarballs).
      
Colm.

>From: Laszlo PETER <Laszlo Peter ireland sun com>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: Darin Adler <darin bentspoon com>
>Cc: Kjartan Maraas <kmaraas online no>, GNOME Hackers 
<gnome-hackers gnome org>, gnome-packaging-list gnome org
>Subject: Re: gnome-1.4.1 beta1
>Content-Transfer-Encoding: 7bit
>
>
>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
>
>_______________________________________________
>gnome-hackers mailing list
>gnome-hackers gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-hackers
>
>


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers