> 1. What process do you use to identify which daily svn changes require
> building new packages? If I am going to support this project then I should
> eat my own dog food and update packages regularly.
I have a cron job that runs every night.  What it does is fire off a bunch
of build scripts in sequence, one for each module (tqtinterface, arts,
kdelibs, kdebase, etc.).  Each build script keeps a record of the SVN
revision number of the last build of that module.  Each build script first
does an "svn up" on the module it wants to build, and if the version
number is not identical to the previous build then it proceeds to upload
the package to the automated QuickBuild build system.

This is where I would like to figure out a way to interface a Slackware
build setup to the QuickBuild backend.  That way you can take advantage of
the computing horsepower available on the QuickBuild cluster as well as
the high speed package mirror.  To do that, I would need to know some
basic things about the Slackware system:
1. All recent releases / codenames from the version you want to support up
through current.
2. Whether a tool exists to create a local copy of the entire Slackware
source and package repository, and where that repository (or repositories)
reside.
3. The configuration file that controls the repository location on an
installed Slackware system, as well as the commands to both perform a full
upgrade and install specific packages by name.
4. The control file format for a Slackware package.  This one is
important, because QuickBuild needs to install all required package
dependencies before the build process starts.  Each build on this system
starts from a bare-bones chroot image so as to avoid any weird
interactions like the one you were describing earlier with mesa.
>
> 2. Any tips about configuring kdevelop? I'd like to start learning C++.
It's pretty easy to use...just run the new project wizard and select a
Hello World C++ or Qt/KDE project.  Look through the code, and when you
want to compile and run just hit Shift+F9.
>
> 3. Is there a way to import trinity svn into a kdevelop project? If I can
> get setup then perhaps I can start trying my hand at small patches.
Not really.  You can use kdevelop to edit the source files in a module,
but the build system remains separate.  What I would suggest is this:
1. Create a copy of the module you want to alter, including all the hidden
.svn files, and change directory to the copy.
2. Run the automake/autoconf/configure portion of your build script (i.e.
everything before the actual "make" command).  This generates all
Makefiles required to compile the code.
3. Edit the C++ source files you are attempting to fix bugs in.
4. Run "make".  The first time it will take a long time, then probably
fail around your changes unless you are a better programmer than most. 
Read the output, fix your code, then run make again.  Note that the second
time around it almost immediately starts compiling the changed
file(s)--this is because all the dependent files were already built with
the initial make command.
5. When you think you have it all fixed and want to test, just run "make
install".  If the fixes work as intended, run "svn diff > patch.diff" to
generate a patch file, which can be uploaded to the bug report detailing
the problem you resolved.  It will be reviewed, and if found acceptable it
will go straight into SVN.

NOTE: If you change ANY Makefile.am files, the entire
automake/autoconf/configure portion of the build script must be re-run
before the make command can be executed again.

Hope this helps anyone trying to get into Trinity development!

Tim