[crossfire] (Automated) Client Snapshot Releases

[Kevin R. Bulgrien]

A script has been developed that automatically creates (debuggable with
sources) snapshot builds of the crossfire clients (tarballs and RPMs,
but no Win32 support).  It has logic to initialize a build environment
from SVN and to update from SVN for each snapshot.  It has been run
through a lot of paces and is far from being a pile of ugly, but some
work could be put into polishing it up to detect/handle build errors,
etc., as it matures.  Presently it does not validate the snapshots in
any way.  It is written to document the release process in code, and to
take the pain out of building (snapshot) releases.  It is reasonable to
think that it can be enhanced to better assist with official release
functions as well.  Though the script produces client tarballs, etc.
It does have to work in the server code base to produce the client files,
so already has some of the functions needed to do a server release.

What might it take to break the blockade on 2.x client releases?  Snapshot 
builds have been mentioned before, and a lot of work on the release process
has been done in response to a general complaint expressed last time this
was brought up.  Are there any good reasons left to avoiding putting the
2.x client out there?  We're going on two years of client enhancements
with no releases.  That can't be helping project exposure any.

What next?  With this script, and with access to another system I could
post snapshots periodically manually, or via some cron process, or, the
script could be opened up to anyone who wanted to support snapshot builds
themselves.  Offers?  Suggestions?

The idea of checking scripts into SVN has been brought up in the past and
has gotten mixed reviews.  This script is one that is really tied in to a
particular aspect of development, so perhaps is more suited to SVN if only
because should facilitate shorter release cycles that have been discussed
from time to time.  While the script could be subordinated to the client
directory, it may be better to have a separate tools/packaging area that
can be used to support client and server releases.  Are there any
objections to creating a tools/trunk/packaging area in SVN, or alternate
specific suggestions?

P.S. Right now my build system is x86_64, and unfortunately x86_64 RPMs
seems to have the "[ 1876788 ] Doubled characters in GTK clients" bug.
This script makes it easier for people to get involved in collecting data
or working on this client issue, and was part of the motivation to write
the script - to remove the pain of rebuilding the client RPMs to test
code changes.