Test your patches before committing. Once you have posted the
'absolutely certainly final' version to RT for comments, you are still
waiting that ~24 hours for possible objections. Keep using patch in
your own system during that time.

 Run autogames - games with only AI players and non-zero timeout. If
you want to test server side only, you can set timeout to -1. If you
want to keep client attached, you may adjust timeout for client to
keep up. Reason I run a lot of server only autogames (in the
background) is that client is more resource hungry, and I'm using this
computer to other things than freeciv testing also.
 If your patch should not change AI behavior (at all / with certain
ruleset), make sure it doesn't. Run long autogame (with known randseed
& mapseed) with and without the patch. Compare final savegames (diff
or md5sum or whatever). If such patch adds or removes something from
savegame, use sed to strip that extra info from savegame and then
compare to one in to which that info was never written to.

 Compile with -Werror (is set by --enable-debug).

 Commit rules allow patch to go in even if it breaks clients other
than gtk. Still, if changes are easily doable, it doesn't hurt to have
other clients in working condition too. You can easily compile all
clients from same sources simply by using separate builddir for each
(this is currently broken for gui-win32, and all have minor issues
with autogenerated source files.)

 If it turns out that your patch makes existing freeciv bug more
serious (freeciv starts crashing when your patch is applied, and its
someone else's fault), those bugs should be fixed *before* you commit
your patch.

 - ML

Freeciv-dev mailing list

Reply via email to