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 Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
