Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 845d42: Add a 'Need more resources' indicator in the power...
On Thursday, 16 February 2012 at 8:42, Per Inge Mathisen wrote: A script should not get a warning for every event it does not implement. If you want to warn about misnamed timers, this function needs an additional bool parameter that is not set for events. If you want to warn about misnamed events, then we could check for functions named event*() but not in the set of defined events on load (could be a job for lint, but not sure if that is the right tool for the job anymore). It looks to me that change adds a warning if we call any undefined function. I noticed this behaviour already when I used a wrong function name, and it took a bit to find the problem, since the game just silently ignored that line. If the script calls a function that doesn't exist, why would we ever not want to know about that? So far, the debuggability of javascript seems not much better than that of wzscript, maybe integrating a QScriptEngineDebugger would help there. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 3.1 release strategy ?
On Friday, 27 January 2012 at 22:36, buginator wrote: Need some clarification on the release strategy. Namely: 3.1 goes into the beta cycle this weekend with the first build. Do we have everything for 3.1-beta1 now? Then I'll do that tomorrow. 3.1.x will be for bug fixes only. 3.2 will be the next feature(s) from master 3.2.x will be bug fixes only. 4.0 will be for major features sitting in the repo in a feature branch. Not sure about that, I'd put features into branches if they are likely to take some time to stabilize, and when they are, merge them for the next release, regardless of what that's called. I don't see an immediate reason for 4.0 since we change the config folder anyway for each 3.x release. The most likely reason seems to go to 4.0 after 3.9 to keep the numbers short. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] -dev eats mails
On Monday, 23 January 2012 at 21:04, buginator wrote: Eh ? where did this come from, I see no mail from dak180 anyplace, so no idea what the context of this was. Seems they get eaten by the mailing list. So what now? A new gna list, where we hope that'll not start eating things? A google group? A sf list (mirrored to a google group for usable archive)? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Fwd] dak...@users.sourceforge.net: Re: The dirt trail to 3.1
- Forwarded message from dak180 dak...@users.sourceforge.net - Date: Fri, 20 Jan 2012 13:39:34 -0500 From: dak180 dak...@users.sourceforge.net To: Development list warzone-dev@gna.org, Christian Ohm chr@gmx.net Subject: Re: [warzone2100-dev] The dirt trail to 3.1 On 2012/01/20, at 12:49 PM, Christian Ohm wrote: Anything else that needs to be done? Are Safety0ff's buffer swap and vexed's lobby patches final? - Possibly wait for the official sdl 1.2.15. Maybe we don't have to wait for that… I would prefer to wait for that for three reasons: it should be released in the next week or so, the delays thus far have been in tracking down a mac related bug and I intend to update not only the SDL version when it goes final but the Qt frameworks used in the mac builds as well. The reason for doing this at the same time is that they have both dropped support in their binary releases for PPC and I plan to do the same, as well as try to see if the latest incarnation of QuesoGLC that we are using will work properly for 64bit intel. - Then branch 3.1, and do a beta1 release immediately. And for this, git-flow or the old way? A properly done git-flow has the advantage of commit hashes being the same in different branches, making changelog writing easier. If we keep the old way, I guess I'll only do it for 3.1, not master. Anyone correct me if I am wrong but I believe that it was decided that we would use a git-flow base method, the only things not finalized were what we were actually going to call the branches. -- My Web Sites: http://dak180.users.sourceforge.net/ - End forwarded message - ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] The dirt trail to 3.1
On Monday, 23 January 2012 at 21:04, buginator wrote: - Possibly wait for the official sdl 1.2.15. http://www.libsdl.org/download-1.2.php It is out. Good. The mingw-cross-env on the server is updated. Maybe we don't have to wait for that... - Then branch 3.1, and do a beta1 release immediately. And for this, git-flow or the old way? A properly done git-flow has the advantage of commit hashes being the same in different branches, making changelog writing easier. If we keep the old way, I guess I'll only do it for 3.1, not master. I am not sure what needs to be done, we keep doing commits (bug fixes) to master like always, and have new features in their own branch, and then finally merge that back into master and remove that branch. If so, that could be quite the challenge trying to get everyone on the same page, and up to speed. It becomes hellish switching to new branches because of compiler cache files and there is currently no way for git to 'pack up' these files when you switch to the new branch, so things become clobbered. Anyway, the main thing about this is, that we are a very small group, and I just don't see people creating feature branches for the heck of it, since most of us just work locally, and when done, we either throw a patch on trac, or just commit it anyway. The only exception to this would be if they are going to alter Warzone in a way that most people wouldn't like, so for major changes, that needs to be in a branch. Well, I'd like for features that potentially break the releasability of master to go into branches, since otherwise we'll end up with the same mess again. Since you already made 3.1, I just want to make sure we are clear on how we will handle this going forward. So far the plan seems to be to ignore it. Namely, once we start up on the 'beta cycle', there will be no new features allowed, it will be locked down, and only bug fixes are applied. Sure. And if we don't need three years again to get to 3.2, we might even succeed there. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] -dev eats mails
Seems they get eaten by the mailing list. So what now? A new gna list, where we hope that'll not start eating things? A google group? A sf list (mirrored to a google group for usable archive)? Oh, and dak180 also mentioned a list with archives running on our server, but that seems too much setup/maintenance work to me. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] The dirt trail to 3.1
So, ehm, do we have a plan for 3.1? From my suggestion: - Scrap the current 3.0. - Update mingw-cross-env to sdl 1.2.15. - Integrate quesoglc. - Make a new 201201xx snapshot. - Possibly fix stuff. We are currently here. Is the template/hq stuff now fixed in git (or could it be done in the scripts now)? Or should we revert the changes for 3.1 and keep them only for master? Anything else that needs to be done? Are Safety0ff's buffer swap and vexed's lobby patches final? - Possibly wait for the official sdl 1.2.15. Maybe we don't have to wait for that... - Then branch 3.1, and do a beta1 release immediately. And for this, git-flow or the old way? A properly done git-flow has the advantage of commit hashes being the same in different branches, making changelog writing easier. If we keep the old way, I guess I'll only do it for 3.1, not master. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] The dirt trail to 3.1
On Friday, 20 January 2012 at 13:39, dak180 wrote: I would prefer to wait for that for three reasons: I don't think it's necessary for a beta, if we get to that before the SDL release, and any rc/final will be after that anyway. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Fwd] build...@wz2100.net: buildbot failure in Warzone2100 on master-nightly
Did someone mess with the server? The buildbot worked yesterday, and I don't see any changes in the repo that would cause this. - Forwarded message from build...@wz2100.net - Date: Tue, 10 Jan 2012 00:33:38 +0100 From: build...@wz2100.net To: chr@gmx.net Subject: buildbot failure in Warzone2100 on master-nightly Build status: FAILURE Buildslave for this Build: *bot-fast-amd64-1* Complete logs for all build steps: http://buildbot.wz2100.net/builders/master-nightly/builds/680 http://buildbot.wz2100.net/builders/master-nightly/builds/680 Build Reason: scheduler Build Source Stamp: *[branch master] cb5842b3d1123af2c6544ccec2d76b60742162c8* Blamelist: dak...@users.sourceforge.net Recent Changes: Repository: git://github.com/Warzone2100/warzone2100.git Project: Time: Mon Jan 9 23:41:13 2012 Changed by: dak...@users.sourceforge.net Comments: Use a better naming scheme for the doc tarball. Files URL macosx/Warzone.xcodeproj/project.pbxproj: None /Detailed log of last build step:/ http://buildbot.wz2100.net/builders/master-nightly/builds/680/steps/configure_1/logs/stdio http://buildbot.wz2100.net/builders/master-nightly/builds/680/steps/configure_1/logs/stdio Last 20 lines of configure_1.stdio checking whether to compile in debug mode... no checking whether the C compiler accepts the -Werror -Wno-switch flag... yes checking whether the C compiler accepts the -Werror -Wno-enum-compare flag... no checking for i686-pc-mingw32-makensis... no checking for makensis... makensis checking for installer version... 2.46.0.0 checking for installer extdir... /wz2100/mingw/usr/i686-pc-mingw32 checking for SDL... ./configure: line 9942: --static: command not found ./configure: line 9950: --static: command not found configure: error: Package requirements (sdl = 1.2) were not met: Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables SDL_CFLAGS and SDL_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. *-The BuildBot* ?? getopt returned character code 0165 u?? ?? getopt returned character code 0171 y?? - End forwarded message - ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-sf-private] [Fwd] build...@wz2100.net: buildbot failure in Warzone2100 on master-nightly
On Monday, 9 January 2012 at 19:04, dak180 wrote: The only thing I can think of is that SDL 1.2.15 is in prerelease and due to become final in a week; someone could have tried to update it, I know vexed was talking about it. I've already installed that some days ago, that's not the problem. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 932d45: Generate the quickstart guide and add it to the ap...
Why do the generated files have to be in git? On Thursday, 5 January 2012 at 7:48, nore...@github.com wrote: Branch: refs/heads/master Home: https://github.com/Warzone2100/warzone2100 Commit: 932d45244dd74dc61a208cf738be2b78e8a3b035 https://github.com/Warzone2100/warzone2100/commit/932d45244dd74dc61a208cf738be2b78e8a3b035 Author: dak180 dak...@users.sourceforge.net Date: 2012-01-05 (Thu, 05 Jan 2012) Changed paths: M .gitignore A macosx/Resources/.gitignore A macosx/Resources/WarzoneHelp/WarzoneHelp.helpindex A macosx/Resources/WarzoneHelp/ar01s01.html A macosx/Resources/WarzoneHelp/ar01s02.html A macosx/Resources/WarzoneHelp/ar01s03.html A macosx/Resources/WarzoneHelp/ar01s04.html A macosx/Resources/WarzoneHelp/ar01s05.html A macosx/Resources/WarzoneHelp/ar01s06.html A macosx/Resources/WarzoneHelp/ar01s07.html A macosx/Resources/WarzoneHelp/ar01s08.html A macosx/Resources/WarzoneHelp/ar01s09.html A macosx/Resources/WarzoneHelp/ar01s10.html A macosx/Resources/WarzoneHelp/ar01s11.html A macosx/Resources/WarzoneHelp/ar01s12.html A macosx/Resources/WarzoneHelp/ar01s13.html A macosx/Resources/WarzoneHelp/ar01s14.html A macosx/Resources/WarzoneHelp/ar01s15.html A macosx/Resources/WarzoneHelp/ar01s16.html A macosx/Resources/WarzoneHelp/ar01s17.html A macosx/Resources/WarzoneHelp/ar01s18.html A macosx/Resources/WarzoneHelp/docbook-xsl.css A macosx/Resources/WarzoneHelp/images/artillery-far-away.jpg A macosx/Resources/WarzoneHelp/images/artillery-sensor.jpg A macosx/Resources/WarzoneHelp/images/attackrange.jpg A macosx/Resources/WarzoneHelp/images/awaymission.jpg A macosx/Resources/WarzoneHelp/images/building-select.jpg A macosx/Resources/WarzoneHelp/images/building.jpg A macosx/Resources/WarzoneHelp/images/cb-sensor-vtol.png A macosx/Resources/WarzoneHelp/images/cb-sensor.png A macosx/Resources/WarzoneHelp/images/cheapweapon.png A macosx/Resources/WarzoneHelp/images/commander-factory-assignment.jpg A macosx/Resources/WarzoneHelp/images/commander-panel.jpg A macosx/Resources/WarzoneHelp/images/commander.png A macosx/Resources/WarzoneHelp/images/commandpanel.png A macosx/Resources/WarzoneHelp/images/design-bars.jpg A macosx/Resources/WarzoneHelp/images/design-more.png A macosx/Resources/WarzoneHelp/images/design-screen.jpg A macosx/Resources/WarzoneHelp/images/design-unit.jpg A macosx/Resources/WarzoneHelp/images/design.jpg A macosx/Resources/WarzoneHelp/images/expensiveweapon.png A macosx/Resources/WarzoneHelp/images/firing.jpg A macosx/Resources/WarzoneHelp/images/hq.png A macosx/Resources/WarzoneHelp/images/indirect-fire-support.jpg A macosx/Resources/WarzoneHelp/images/intelligencedisplay.jpg A macosx/Resources/WarzoneHelp/images/interface.jpg A macosx/Resources/WarzoneHelp/images/logo.png A macosx/Resources/WarzoneHelp/images/manufacture-select.jpg A macosx/Resources/WarzoneHelp/images/manufacture.jpg A macosx/Resources/WarzoneHelp/images/minimap.jpg A macosx/Resources/WarzoneHelp/images/movement.jpg A macosx/Resources/WarzoneHelp/images/oilresource.jpg A macosx/Resources/WarzoneHelp/images/powerbar.jpg A macosx/Resources/WarzoneHelp/images/powerupgrade.png A macosx/Resources/WarzoneHelp/images/rallypoints.jpg A macosx/Resources/WarzoneHelp/images/recycling.jpg A macosx/Resources/WarzoneHelp/images/research-select.jpg A macosx/Resources/WarzoneHelp/images/research.jpg A macosx/Resources/WarzoneHelp/images/retreatthreshold.jpg A macosx/Resources/WarzoneHelp/images/return.jpg A macosx/Resources/WarzoneHelp/images/satellite-uplink.png A macosx/Resources/WarzoneHelp/images/sensor-tower.png A macosx/Resources/WarzoneHelp/images/sensor.png A macosx/Resources/WarzoneHelp/images/transport.jpg A macosx/Resources/WarzoneHelp/images/unitordersmenu.jpg A macosx/Resources/WarzoneHelp/images/wss.png A macosx/Resources/WarzoneHelp/images/www.png A macosx/Resources/WarzoneHelp/index.html A macosx/Resources/WarzoneHelp/javascript.pdf A macosx/Resources/WarzoneHelp/warzone2100.6.html M macosx/Warzone.xcodeproj/project.pbxproj Log Message: --- Generate the quickstart guide and add it to the app bundle. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Building both the Qt and SDL version
https://github.com/cybersphinx/warzone2100/commits/master builds both versions (if the needed stuff is available). That results in src/warzone2100qt and src/warzone2100sdl, and possibly leaves an old src/warzone2100 around to confuse people. Do we want to make one of the new ones take over that name? Probably needs menu entries for both versions as well. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Building both the Qt and SDL version
https://github.com/cybersphinx/warzone2100/commits/master Hm, looks like that doesn't build from a clean tree, sorry. Stupid automake. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Fwd] build...@wz2100.net: buildbot failure in Warzone2100 on master-nightly
- Forwarded message from build...@wz2100.net - Build status: FAILURE Buildslave for this Build: *bot-fast-amd64-1* Complete logs for all build steps: http://buildbot.wz2100.net/builders/master-nightly/builds/422 http://buildbot.wz2100.net/builders/master-nightly/builds/422 Build Reason: scheduler Build Source Stamp: *[branch master] 442871d433ee1661ceaf0c8199dc3fcad8a85910* Blamelist: jo...@sapo.pt,pe...@sonowand.com Recent Changes: Repository: git://github.com/Warzone2100/warzone2100.git Project: Time: Tue Oct 4 00:46:07 2011 Changed by: jo...@sapo.pt Comments: doxygen documentation added on order.h and ordered.h. enums were aligned, and almost everything regarding orders are now documented. Files URL src/order.cpp: None src/order.h: None src/orderdef.h: None Repository: git://github.com/Warzone2100/warzone2100.git Project: Time: Tue Oct 4 00:46:07 2011 Changed by: jo...@sapo.pt Comments: Added some small fixes to the committed code, mainly regarding indentation. Files URL src/order.cpp: None src/order.h: None src/orderdef.h: None Repository: git://github.com/Warzone2100/warzone2100.git Project: Time: Tue Oct 4 01:26:54 2011 Changed by: jo...@sapo.pt Comments: Doxygen documentation changed to JavaDoc styling. Small other typos fixed. Files URL src/order.cpp: None src/order.h: None src/orderdef.h: None Repository: git://github.com/Warzone2100/warzone2100.git Project: Time: Tue Oct 4 18:57:33 2011 Changed by: pe...@sonowand.com Comments: Merge pull request #22 from littlepig/topic/doxygen Doxygen documentation added to order.cpp, order.h and orderdef.h /Detailed log of last build step:/ http://buildbot.wz2100.net/builders/master-nightly/builds/422/steps/compile/logs/stdio http://buildbot.wz2100.net/builders/master-nightly/builds/422/steps/compile/logs/stdio Last 20 lines of compile.stdio ../../src/group.h:41: error: âEUR~DROIDâEUR[tm] has not been declared ../../src/group.h:42: error: âEUR~DROIDâEUR[tm] has not been declared ../../src/group.h:46: error: âEUR~DROID_ORDERâEUR[tm] has not been declared ../../src/group.h:47: error: âEUR~DROID_ORDERâEUR[tm] has not been declared ../../src/group.h:48: error: âEUR~DROID_ORDERâEUR[tm] has not been declared ../../src/group.h:50: error: âEUR~SECONDARY_ORDERâEUR[tm] has not been declared ../../src/group.h:50: error: âEUR~SECONDARY_STATEâEUR[tm] has not been declared In file included from ../../src/multiplay.h:28, from textdraw.cpp:33: ../../src/group.h:54: error: ISO C++ forbids declaration of âEUR~DROIDâEUR[tm] with no type ../../src/group.h:54: error: expected âEUR~;âEUR[tm] before âEUR~*âEUR[tm] token ../../src/group.h:55: error: ISO C++ forbids declaration of âEUR~DROIDâEUR[tm] with no type ../../src/group.h:55: error: expected âEUR~;âEUR[tm] before âEUR~*âEUR[tm] token ../../src/group.h:56: error: âEUR~RUN_DATAâEUR[tm] does not name a type make[3]: Leaving directory `/home/buildbot/slaves/warzone2100/master-nightly/build/lib/ivis_opengl' make[3]: *** [textdraw.o] Error 1 make[2]: Leaving directory `/home/buildbot/slaves/warzone2100/master-nightly/build' make[2]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/buildbot/slaves/warzone2100/master-nightly/build' make[1]: *** [all] Error 2 *-The BuildBot* ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] build error
On Thursday, 29 September 2011 at 20:39, mikej...@comcast.net wrote: I tried to build it with mingw but got the following error. Any ideas? C:/test/wz/devpkg/lib/libz.a(inflate.o):inflate.c:(.text+0xa0): multiple definition of `inflatePrime' C:/test/wz/devpkg/lib/libphysfs.a(inflate.obj):/home/dschridde/Projects/Warzone/devpkg/src/physfs-2.0.0/zlib123/inflate.c:132: first defined here C:/test/wz/devpkg/lib/libz.a(inflate.o):inflate.c:(.text+0x2a0): multiple definition of `inflateGetHeader' C:/test/wz/devpkg/lib/libphysfs.a(inflate.obj):/home/dschridde/Projects/Warzone/devpkg/src/physfs-2.0.0/zlib123/inflate.c:1214: firs t defined here C:/test/wz/devpkg/lib/libz.a(crc32.o):crc32.c:(.text+0x310): multiple definition of `crc32_combine' C:/test/wz/devpkg/lib/libphysfs.a(crc32.obj):/home/dschridde/Projects/Warzone/devpkg/src/physfs-2.0.0/zlib123/crc32.c:374: first def ined here C:/test/wz/devpkg/lib/libz.a(adler32.o):adler32.c:(.text+0x290): multiple definition of `adler32_combine' C:/test/wz/devpkg/lib/libphysfs.a(adler32.obj):/home/dschridde/Projects/Warzone/devpkg/src/physfs-2.0.0/zlib123/adler32.c:132: first defined here Looks like a conflict between zlib and physfs (which has its own zlib inlcuded). C:/test/wz/devpkg/lib/libfontconfig.a(fcfreetype.o):fcfreetype.c:(.text+0x1b8a): undefined reference to `libiconv_open' C:/test/wz/devpkg/lib/libfontconfig.a(fcfreetype.o):fcfreetype.c:(.text+0x21b0): undefined reference to `libiconv' C:/test/wz/devpkg/lib/libfontconfig.a(fcfreetype.o):fcfreetype.c:(.text+0x21bd): undefined reference to `libiconv_close' C:/test/wz/devpkg/lib/libfontconfig.a(fcfreetype.o):fcfreetype.c:(.text+0x27aa): undefined reference to `libiconv_close' C:/test/wz/devpkg/lib/libfontconfig.a(fcfreetype.o):fcfreetype.c:(.text+0x2828): undefined reference to `libiconv_close' Missing iconv? The mingw build is unmaintained though, so we can't help you much there unfortunately. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Videos have been re-encoded
On Thursday, 22 September 2011 at 22:57, buginator wrote: Forum member Ezio has re-encoded the video files. The thread is located here: http://forums.wz2100.net/viewtopic.php?f=6t=7796 They have done: 480pv3 4:3 919 MB and 720p 4:3 1.04 GB Right now, we have low quality and standard quality. We could drop the standard, and have low 480p (don't think there is much demand for 720p because of the problems discussed in that thread) or go with low / std / high. What do you all think ? Has anyone looked at the 720p (and could upload devastation.ogg somewhere)? Sounds like an exercise in futility to me, both because we probably can't play them properly due to the resolution, and because they won't improve things much (as also seen in the filesize, over twice the pixels per frame, but not much larger files). Personally, I'd drop the low quality rather than normal, the German videos are only available in that, and I don't remember much (if any) requests for a smaller version. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Lobby leaks file descriptors?
Seeing someone complain about the lobby being down and restarting it, I had a look a the logs. They're full of 2011-08-24 16:24:14+0200 [twisted.internet.protocol.ServerFactory] Could not accept new connection (EMFILE) which seems to indicate it can't open any more files, probably because it doesn't close them properly. Simple solution would be a cron job to restart it daily or something. Also, gzipping the .X log files would save quite a bit of disk space, we have almost 700 MB of lobby logs now. Also, it would be nice if http://buildbot.wz2100.net/files/ was sorted by date, or the filenames get a timestamp. Also, we still don't get failure emails from the buildbot. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Fwd] st...@sk2.org: warzone2100 and libiberty with mingw-w64
- Forwarded message from Stephen Kitt st...@sk2.org - Date: Wed, 20 Jul 2011 15:34:47 +0200 From: Stephen Kitt st...@sk2.org To: Christian Ohm chr@gmx.net Subject: warzone2100 and libiberty with mingw-w64 Hi, You requested that I ship libiberty in the gcc-mingw-w64 packages, since warzone2100 uses it. The current version in Debian unstable ships these files, but I noticed while working on a new upload of gcc-mingw-w64 that gcc no longer considers libiberty to be a target library, and the gcc build system no longer supports building and installing libiberty.a for cross-compiler targets; this means that, unless I change the build system, future versions of the gcc-mingw-w64 package will no longer provide libiberty.a. Given that target-libiberty is explicitly dropped upstream, I don't think restoring it is viable in the long term; see http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00374.html for the discussion which led to the removal, which has its own thread starting at http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01504.html with the patch following at http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01693.html. The patch is now included in the GCC Subversion repository and in current gcc-4.6-source package (hence the gcc-mingw-w64 FTBFS bug, http://bugs.debian.org/634567.) The suggestion for software using libiberty is to use gnulib instead. From what I understand, this might not be enough for warzone2100 since it uses Dr. MinGW, and needs libiberty for that. Do you have any idea whether it would be possible for warzone2100 to use Dr. MinGW directly, either by shipping its source or by supporting the use of an external Dr. MinGW other that libiberty? Or am I barking up the wrong tree? If this doesn't concern you I'm sorry for bothering you. Feel free to forward this if other people should be involved! Regards, Stephen - End forwarded message - ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 793c30: Merge branch 'bsonlobby' into master
On Saturday, 9 July 2011 at 12:21, buginator wrote: Note, it seems that the license for this stuff is Apache 2, and that doesn't mesh well with our license, so, I believe, that we can't have this in our repo. It doesn't look like having static or dynamic version of this changes anything either. From a quick look at bson I don't really see any version that meshes well with GPL v2... Is there any major advantage in using bson over json? There seem to be way more implementations available, with suitable licenses. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] test
-- A rock store eventually closed down; they were taking too much for granite. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Campaign resource loading
On Sunday, 8 May 2011 at 18:20, Kreuvf wrote: 08.05.2011 15:41, Per Inge Mathisen wrote: [General] name = Basic Tutorial Difficulty = Easy Map = data/base/wrf/tutorial/newtut.gam Script = script/tutorial/tutorial.js Data = data/base/wrf/tutorial/newtut.wrf Is the name translatable? Is the ini loader able (to be hacked) to ignore _() around string values? Then we could just have lines like name = _(Basic Tutorial) which automatically get added to the po files. I guess for the integrated iniparser in 2.3 that'd be not that much of a problem, not sure if that'd work on master tough. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.8 and Milestones
Updated the milestone. Barring objections, I intend to push all that the next days (except the docs, that needs to be integrated into the build system etc.). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.8 and Milestones
On Saturday, 30 April 2011 at 16:01, Guangcong Luo wrote: On Sat, Apr 30, 2011 at 3:34 PM, Rene jochum rene.joc...@pc-dummy.net wrote: Can you setup a Test-mod for that? Would be great if we can test this first. It's a bit late to do balance testing for 2.3.8 at this stage. Knowing Not that there weren't three months to do it... that Iluvalar has done balance testing, I don't think committing a milder form of his changes will require separate testing, but if you insist, we might want to hold off committing flamer changes for a later release. Are the flamer changes related to being able to build on burning oil? I've added a patch to http://developer.wz2100.net/ticket/1100 that might solve that problem. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.8 and Milestones
On Friday, 29 April 2011 at 10:20, Kreuvf wrote: I'd like to update the German translation for 2.3.8, hopefully I have time for it this weekend. If not, go without an updated translation. For 2.3 that's only three strings, master has about 120 untranslated/fuzzy. No other changes that should be done for 2.3.8? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3.8 and Milestones
Since Fastdeath made the Milestone field in trac unchangeable by normal users, we can actually use it now to track release progress, without every new ticket getting in the way. I've set http://developer.wz2100.net/ticket/2386 to 2.3.8 now, are there other problems that need to be solved for that? It has some changes that should be released soon imo, so preferably only tickets that actually have a solution. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Wednesday, 27 April 2011 at 9:53, Kreuvf wrote: 26.04.2011 22:10, Christian Ohm wrote: I'd like to see a move towards a process that doesn't result in countless started things that need to be finished before we can even begin to think about a release. But isn't this one of the inherent problems of FLOSS development? The started things that might take long or never be finished, yes. Developing those in the main development branch directly where they affect everyone seems more like an inherent problem of SVN to me (which people then carry over to newer VCSs). The GIMP devs also struggle with that: http://www.chromecode.com/2011/02/why-gimp-28-is-not-released-yet.html ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Wednesday, 27 April 2011 at 20:54, Fastdeath wrote: What I do not quite understand: (Generally, merges go only in one direction, no back-merges from master into other branches.) that means we are not allowed to back merge branch unrelated bugfixes? That means that you don't merge master (or other branches) back into the feature branches, so all commits in a branch are exclusively about its feature, without unrelated changes. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Sunday, 24 April 2011 at 21:28, Daniel Kliman wrote: It sounds like the development model described in http://nvie.com/posts/a-successful-git-branching-model/ Mostly it is influenced by the Linux kernel development process (arguably the group of users most familiar with git). Is that what you would like to see us move towards? I'd like to see a move towards a process that doesn't result in countless started things that need to be finished before we can even begin to think about a release. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Sunday, 24 April 2011 at 18:55, Per Inge Mathisen wrote: On Sun, Apr 24, 2011 at 12:43 PM, Christian Ohm chr@gmx.net wrote: I've wondered if the concept of stable release is actually useful for us. It is useful for users. Hm, that was supposed to read stable release branch. We bare can keep 2.3 alive, I don't think we need another branch that needs attention. We should definitely aim for quicker releases later on. Not really sure how to do this. I think this is mostly dictated by what we want to do and how much time people have, anyways. I think the feature branches model is our best bet to achieve that. master won't ever have unfinished stuff delaying a release, and features can be developed in a branch as fast or slow as wanted without delaying a release. That does sound like an interesting idea. I think the linux distros would hate it, though. They don't like apps having their own update mechanisms. But maybe if it was just for data (including scripts)? That was mostly aimed at Windows. No idea about Macs, the commercial games on Linux I know (mostly from the Humble Bundles) tend to have their own LD_PRELOADed libs included, and when things fail you need to remove some of them so the system libs are used... So on Linux at least, we already have all the git autoupdate that's needed imo. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Tuesday, 26 April 2011 at 16:31, dak180 wrote: I have yet to see a clear illustration of how the kernel development is managed can you point to what you would consider to be the best such? http://en.wikipedia.org/wiki/Linux_kernel#Development_model for a summary, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=Documentation/development-process for the details. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Tuesday, 26 April 2011 at 23:05, Per Inge Mathisen wrote: I still remember lua branch, qt branch, netsync branch, and terrain branch that festered like bad wounds while we struggled with lack of testing and little idea what to do with them until they were merged more or less untested (less true for netsync than the others, but it still had a long way to go after merging). I do not believe this is a silver bullet. A wip integration branch where all feature branches get merged together with git's better merge support should help there. Though yes, too long lived branches might also not work well with this model (or our spaghetti code). And I'm open to other proposals, I'm not saying this is the one true way to do things. It is just a way that seems to work well for others. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Sunday, 24 April 2011 at 10:04, Per Inge Mathisen wrote: This will have some consequences, like not being able to aim for a stable release from master in a while, I've wondered if the concept of stable release is actually useful for us. Looking at 2.3, it seems to languish mostly, while people work on new stuff. So, proposal for a more git-like workflow: -1. Get master into a reasonably stable state. 0. New features are developed in feature branches. Bugfixes to a specific feature go into the feature branch as well, even after it got merged. (Generally, merges go only in one direction, no back-merges from master into other branches.) 1. Merge feature branches deemed ready. 2. Test and get them really ready. 3. Release. 4. Goto 1. That way new features get released reasonably quickly, and we don't have to keep care of an outdated release branch. Also, work on features doesn't destabilize master before they're merged, and if they do after merging, they can be unmerged relatively easy again. Could maybe be enhanced with a wip branch where all currently worked on feature branches get merged regularly, to see how they work together. If a bugfix release is needed before the next proper release, it can just be branched from the release as needed. * We merge Qt branch into master immediately. No objections from me. * Once a new map format is ready, we can start experimenting with a new map renderer. Of course, these things go together, so I assume that the new map format will have a few revisions before it is stabilized. * The new map renderer should use shaders, but not require as much hardware as the current. Consider this statement ironical? Only if you have made a habit out of thinking that poor drivers mean weak hardware. But lots of recent weak/cheap hardware now have quite decent OpenGL ES 2 drivers. The new map renderer needs to be fast, maintainable, and extensible. Shouldn't that just read renderer? I think our speed problem is still mostly model rendering. * Meanwhile, we also need to get rid of the old scripting system, and I am on the way there with the QtScript port. I am hoping that I can concentrate on this, while someone else have a go at the map renderer. This task does not need to be finished before stable release, but the new script API should be stable by then. You said that scripts don't need to be deterministic because they can just run locally and send the results to other players. So a new way to cheat is to just run a custom script? Other items that would be nice to have before a stable release: * Login support for the game and masterserver. * Observers. * Replay. I've had this idea of having a git repository for each savegame, with a save committed every game tick. That could allow to replay, rewind and bisect games. (Maybe every tick is too much, even with a background thread though.) And when we have e.g. libgit2 integrated anyway, we could use it as autoupdate mechanism. A new release gets committed to the repo, the game automatically pulls it. Can also be used to detect manipulated data files. Though we might have to use single files instead of zip archives for the data, I think git doesn't do binary changes well (bup might help though: https://github.com/apenwarr/bup). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] request to remove 3rd party libs that we embed
On Thursday, 17 March 2011 at 20:38, buginator wrote: Pabs3 mentioned that we should remove all embedded 3rd party libs, and I am OK with this. This would mean we remove glee from source, as well as miniupnp. I think the iniparser stuff is custom, though I am not 100% sure. Objections ? I've mailed our one segfault preventing patch to the miniupnp upstream, once that's included I don't have any objections to removing it. Though some distros might not have it included, I guess that's more incentive for them to package it. Iniparser in master is a rewrite by Evilguru, 2.3 still has the old version I think. And about glee/glew, I don't care, whatever works with the cross-compiler. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #1066: Warzone doesn't support non-ASCII chars in PhysFS 2.0.0
On Monday, 28 February 2011 at 19:55, Safety0ff wrote: The precompiled version of physfs should be removed from the tarball (I've set things such that the Physfs 2 build overwrites the files from the tarball for the time being). As mentioned on IRC, we either need to add a tarball without physfs with different name, or just keep overwriting the old files. I don't care much about which solution is chosen, as long as nothing breaks. (Actually I'm thinking about using mingw-cross-env instead of our custom cross-build system, then a. other people can care about package versions etc, and b. it already includes qt (though not some other packages we use).) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] correction for fr.po in trunk
On Thursday, 24 February 2011 at 0:00, Gilles J. Seguin wrote: typo correction tirreur - tireur Applied, thanks. Please attach the whole po file in the future though, that makes applying it easier. fr.po.diif is svn diff fr.po in trunk Looks like you're still using the old svn repo, our current repo is at https://github.com/Warzone2100/warzone2100. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Directory layout changes for future build system
On Saturday, 15 January 2011 at 1:18, Safety0ff wrote: Hi all, While working on a CMake build system I took the opportunity to move the contents from lib to src. I don't see what that gains us, to me it'll only lead to confusion between old and new layout and breaking of existing patches/branches. Somewhat loosely related, what would be good imo is a lib/3rdparty directory, for all the third party code we include. The rationale for this was: 1) It helped me to keep the build system rational without compiling some of the parts into libraries (like the current system does.) Even automake can build the whole Warzone without building separate libraries (though it's not configured that way atm). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Fwd] softw...@heise.de: Your software is now being hosted
- Forwarded message from softw...@heise.de - Date: Mon, 29 Nov 2010 18:24:08 +0100 From: softw...@heise.de Subject: Your software is now being hosted Dear software manufacturer, your software Warzone 2100 is listed in the heise software directory at http://www.heise.de/software/download/warzone_2100/56364 and we recently started offering version 2.3.6 (warzone2100-2.3.6.exe) for download. Fortunately, our automatic virus checks (done in co-operation with AV-Test GmbH) with more than 40 virus scanners do not indicate a virus infection. Just in case you are interested in the scan result we are sending you the detailed scan report: Scan report of: 25301-warzone2100-2.3.6.exe AntiVir - Authentium - Authentium (Online) - Avast - AVG - BitDefender - CA-AV - ClamAV - Eset Nod32 - Fortinet- Fortinet (BETA) - F-Prot - Ikarus - ISS VPS - K7 Computing- Kaspersky - Kaspersky (Online) - McAfee - McAfee (BETA) - McAfee (Online) - McAfee GW Edition (Online) - Microsoft - Norman - Panda - Panda (Online) - PC Tools- QuickHeal - Rising - Sophos - Sophos (Online) - Spybot SD - Sunbelt - Symantec- Symantec (BETA) - Trend Micro - Trend Micro (Cons.) - Trend Micro (CPR) - VBA32 - VirusBuster - Webroot - The following updates have been used for the test (all times in GMT): AntiVir vdf_fusebundle.zip 2010-11-29 16:10 Authentium antivir-z-201011291452.zip 2010-11-29 15:19 Authentium (Online) antivir-z-201011291452.zip 2010-11-29 15:19 Avast av5db.zip 2010-11-29 10:39 AVG avg90cmd869a3848.zip2010-11-29 13:28 BitDefender bdc.zip 2010-11-29 15:45 CA-AV fv_nt86.exe 2010-11-29 08:14 ClamAV daily.cvd 2010-11-29 14:18 Eset Nod32 minnt3.exe 2010-11-29 16:53 Fortinetvir_high2010-11-29 16:58 Fortinet (BETA) vir_high2010-11-29 13:22 F-Prot antivir.def 2010-11-28 19:07 Ikarus t3sigs.vdb 2010-11-29 13:41 ISS VPS VPS.rar 2009-12-31 00:15 K7 Computingk7cmdline.zip 2010-11-29 14:46 Kaspersky kdb-i386-cumul.zip 2010-11-29 16:35 Kaspersky (Online) kdb-i386-cumul.zip 2010-11-29 16:35 McAfee avvdat-6182.zip 2010-11-29 16:14 McAfee (BETA) avvwin_netware_betadat.zip 2010-11-29 17:05 McAfee (Online) avvdat-6182.zip 2010-11-29 16:14 McAfee GW Edition (Online) mfegw-cmd-scanner-windows.zip 2010-11-29 16:56 Microsoft scnAVavdlta1958080.cab 2010-11-29 13:55 Norman nvc5oem.zip 2010-11-29 12:26 Panda pavexp_sig.zip 2010-11-29 16:29 Panda (Online) pavexp_sig.zip 2010-11-29 16:29 PC Toolsavdb.zip2010-11-29 16:26 QuickHeal qhadvdef.zip2010-11-29 16:20 Rising RavDef.zip 2010-11-29 01:56 Sophos ides.zip2010-11-29 12:46 Sophos (Online) ides.zip2010-11-29 12:46 Spybot SD includes-all.zip2010-11-29 11:43 Sunbelt CSE39VT-EN-7445-F.sbr.sgn 2010-11-29 15:37 Symantecstreamset.zip 2010-11-29 17:12 Symantec (BETA) symrapidreleasedefsi32.exe 2010-11-29 15:31 Trend Micro lpt659.zip 2010-11-29 08:11 Trend Micro (Cons.) cvsapi659.zip 2010-11-29 09:02 Trend Micro (CPR) lpt660.zip 2010-11-29 16:51 VBA32 vba32w-latest.rar 2010-11-29 09:55 VirusBuster vdb.zip 2010-11-29 16:57 Webroot antivirus.rar 2010-11-29 09:35 Greetings, your heise software team - End forwarded message - ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Fwd] mano...@users.sourceforge.net: Help Wanted - Mac developer needed for W
- Forwarded message from mano...@users.sourceforge.net - Date: Wed, 17 Nov 2010 15:53:18 + From: mano...@users.sourceforge.net To: the_cybersph...@users.sourceforge.net Subject: Help Wanted - Mac developer needed for W Hello there, I am just finished my studies about computer systems (C,java,PHP programming) and i would like to join on a project that i could help as much as i cant and also improve my skills on programming. If you think that i can help you on your project please answer me. -- This message has been sent to you, a registered SourceForge.net user, by another site user, through the SourceForge.net site. This message has been delivered to your SourceForge.net mail alias. You may reply to this message using the Reply feature of your email client, or using the messaging facility of SourceForge.net at: https://sourceforge.net/sendmessage.php?touser=3134028 - End forwarded message - -- Ignorance is the soil in which belief in miracles grows. -- Robert G. Ingersoll ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] The gitorious repo sucks because it's missing history
The git repo on gitorious doesn't have all the history from svn, which makes it somewhat painful to retrace old changes. My local git-svn repo was way better in that regard. Is there a way to redo the repo from svn, doctor the transition from old to new svn (berlios to gna) to give continuous history, clean it up with svn2git, and put all new commits on top of that? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] The gitorious repo sucks because it's missing history
On Wednesday, 3 November 2010 at 12:46, dak180 wrote: This is git, (so in keeping with git=MacGyver) there is a way (perhaps even more than one); the real question is what is the cost of doing so and is the outcome worth that cost? If it's possible, I'll do the doctoring, so the cost is mostly all current repos being invalidated and everyone having to reclone. The benefit is proper history, imo that's worth it. The question is, is it possible to rebase a complete repo on top of a different base while keeping timestamps etc.? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Qt branch
On Monday, 11 October 2010 at 9:27, Per Inge Mathisen wrote: I was told by Zarel and cybersphinx earlier that you absolutely needed resolution changing before qt-branch could be merged, and now that I've started working on it, you tell me you do not want it anyway? (http://forums.wz2100.net/viewtopic.php?f=4t=6611) Instead you come up with new arguments why windowed fullscreen is unacceptable, which would have been nice to hear before we spent a ton of time polishing qt-branch to be merge-worthy. Really. Disappointing. The fvwm case is more of an annoyance, since you can e.g. configure a key combo to toggle it. It just was a concrete example for edge-activated things, since I don't know what modern desktop stuff does. I think I've always said that I don't like the qt-fullscreen mode (I can do what qt does with the sdl version already), not sure if I've specified why, since my case is fairly uncommon. My only real concern is resolution switching, sdl's take-over-everything approach works fine there, we'll see how the custom qt version works out. (Well, there's also Windows cross-compiling, but that is Not My Problem™.) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] How to handle 2.3?
On Tuesday, 14 September 2010 at 11:31, Giel van Schijndel wrote: On Tue, Sep 14, 2010 at 12:56:53AM -0400, buginator wrote: On 9/13/10, Christian Ohm wrote: So how long would this bugfix 2.3 live? Until 2.5 is done, and then 2.4 is fixes only? By what criteria will the jump to 2.5 happen? I am not really sure what the new criteria will be required for a major version bump. Is it netcode ? Gfx ? Lobby code ? Other ? Dunno. Might I suggest a blasphemous approach? Only *officially* maintaining a single 2.X branch at a time, i.e. as soon as 2.4 is released support for 2.3 is dropped. I explicitly emphasised officially there to allow for the case that we have a very simple bugfix which someone is willing to backport. How about doing 2.3.5.x releases for bugfixes only instead? So for example we (finally) branch 2.3.5 now (and immediately push CorvusCorax's projectile fixes in 2.3 for 2.3.6), tag (hopefully no more) RCs from it, the release, and the 2.3.5.x fixes. I can live with this. I don't think we have enough manpower to maintain two release branches. (Well, and there's the question of how well the bugfix only thing will work out, I remember both the 2.2 and 2.3 jumps, and though both times there was some interest in keeping the old line alive in parallel for a while, in the end only the new version was released.) This is true as well, and since we always lack the manpower to do the upkeep that is required, it is possible the same thing will happen with the purposed 2.3.5.x branch. We are going to end up with 3 testing versions, one for trunk (new features + bug fixes), one for 2.X (new features + bug fixes), and one for 2.3.5.x (bug fixes). It might not always be possible to just do testing in 2.X, since the new feature might skew the results. Another radical suggestion: reducing 2.X branches to feature-frozen branches, i.e. the only time to add new features would be when creating a new 2.X branch. How's that different from what I proposed? Sounds about the same to me, except you use 2.x instead of 2.3.x. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] How to handle 2.3?
On Sunday, 12 September 2010 at 22:24, buginator wrote: On 9/12/10, Christian Ohm wrote: The way I'd do 2.3 releases is: 0. Make Fastdeath's server build daily SVN snapshot builds, so hopefully the changes in current SVN get a bit more exposure before being in a RC. 1. Branch a release branch off from 2.3 (either abusing a tag, or making a separate branch and tag from that), branches/2.3.6 for example. 2. Prepare the first RC and release that. If using branches/xxx, the tag is only a copy of the current branch without further changes. 3. Commits go to 2.3, and only those fixing problems discovered in the rc are backported. 4. Goto 2. until no new problems appear and the last rc becomes the release. That allows normal commits into 2.3 as usual, without delaying them until after the release. It also means fixes need to go into two (or three, including trunk) branches, but that should serve as an incentive to keep the rc cycle short :P. As for going to 2.4, I currently don't see much reason for it. We're doing more than pure bugfix releases, but not enough new features to justify the higher number imo (or we do that for every release...), so I prefer staying with 2.3.x for now. Or does anyone have features planned that need a new version? Our repo doesn't behave like a normal repo anymore, where 'trunk' is used for testing, and then branch from that for the next release. I was going to change GAMESTRUCT to add more requested enhancements, and that will require a masterserver change... However, that doesn't really mean we need a new major version for that. It is just that I was thinking that 2.3.x will only get bug fixes only (from now on), and all new features will go into a new 'base' branch that we can use like a trunk, and then have snapshots (weekly or as needed) out for testing. I know this was tried before, and things (features) kept slipping in, but the way things are working out isn't really maintainable. I rather not have multiple fixes that fix fixes since it was a new feature, and not strictly a bug fix for a 'stable' branch. So how long would this bugfix 2.3 live? Until 2.5 is done, and then 2.4 is fixes only? By what criteria will the jump to 2.5 happen? How about doing 2.3.5.x releases for bugfixes only instead? So for example we (finally) branch 2.3.5 now (and immediately push CorvusCorax's projectile fixes in 2.3 for 2.3.6), tag (hopefully no more) RCs from it, the release, and the 2.3.5.x fixes. I realise that half of it is just naming, but the other thing is that we currently use .warzone2100-2.3 as config folder, and I don't think most planned additions will break something in it (and I don't think reusing the 2.3 folder for 2.4 is a good idea). I think my proposal should work out about the same as yours, just with less disturbance both for users and in SVN. (Well, and there's the question of how well the bugfix only thing will work out, I remember both the 2.2 and 2.3 jumps, and though both times there was some interest in keeping the old line alive in parallel for a while, in the end only the new version was released.) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] commit messages
On Sunday, 12 September 2010 at 14:12, Stephen Swaney wrote: Two commit messages - compare and contrast: Log Message: --- Fix bug #2147, fix bug #2158, remove VTOL Flak Cannon (doesn't make sense lore-wise, and did too much friendly fire to be useful). That doesn't tell much about what the actual change was (and even if it doesn't need to be mentioned, that can't be determined from the message (unless you classify all changes with no useful message as irrelevant)). Log Message: --- Fix lobby glitch to update everything when netPlayersUpdated is true and force localOptionsReceived to be true as well, since that is what controls the drawing routines. Fixes ticket:2136 This one tells what was changed, but not why, the reason is also hidden in the ticket. Now imagine you are trying to make a Changelog. Which one is more useful to you? Hint to forestall nitpicking over these specific msgs: One msg requires looking up the specific bug in Trac in order to add something meaningful to the Changelaog. Both bad, the second slightly less because it's only one ticket to look up. :P The other one provides something that can be cut pasted. ... if you don't care about it actually telling the users what this change is about. My preferred commit message format is: What was changed. Reason why it was done, maybe why it was done the way it was done, the tickets it fixes. So a short summary that's less than 80 characters, and a description with more details, if needed. git uses that format, and when you email a patch, the first line becomes the subject, and the rest the message body. So ideally commit message and patch are a self-contained unit, that should work well for changelog writing. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] How to handle 2.3?
The way I'd do 2.3 releases is: 0. Make Fastdeath's server build daily SVN snapshot builds, so hopefully the changes in current SVN get a bit more exposure before being in a RC. 1. Branch a release branch off from 2.3 (either abusing a tag, or making a separate branch and tag from that), branches/2.3.6 for example. 2. Prepare the first RC and release that. If using branches/xxx, the tag is only a copy of the current branch without further changes. 3. Commits go to 2.3, and only those fixing problems discovered in the rc are backported. 4. Goto 2. until no new problems appear and the last rc becomes the release. That allows normal commits into 2.3 as usual, without delaying them until after the release. It also means fixes need to go into two (or three, including trunk) branches, but that should serve as an incentive to keep the rc cycle short :P. As for going to 2.4, I currently don't see much reason for it. We're doing more than pure bugfix releases, but not enough new features to justify the higher number imo (or we do that for every release...), so I prefer staying with 2.3.x for now. Or does anyone have features planned that need a new version? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.5 RC ETA in 1-2 days?
On Friday, 3 September 2010 at 14:37, Guangcong Luo wrote: On Fri, Sep 3, 2010 at 2:24 PM, Christian Ohm chr@gmx.net wrote: Do you know the difference between open source and commercial software? Commercial software has to make users happy, because they pay the developers. Open source software has to make the developers happy. This, perhaps, is were most of our disagreements stem from. I'm not saying we should completely ignore users. And I'm sure making users happy is a way for at least some developers to get happy themselves. I am just saying, ignoring developers for the sake of users isn't good. On that note, I finally realized what bugged me about this release: The commit messages. There have been quite a few quite useless messages lately. I've spent a considerable amount of time the last releases to write a decent changelog. Commit messages like this are detrimental to my motivation to do that, which in turn is detrimental to my motivation to do releases. ...you said commit messages like this, but you didn't link/name/quote a specific commit. Was that a typo? It referred to useless messages earlier. Actually looking at it again now it's not that bad, just a few of the network changes, maybe I was too tired before... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11573] branches/2.3/src/multiplay.c
On Thursday, 2 September 2010 at 5:40, bugina...@users.sourceforge.net wrote: Revision: 11573 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=11573view=rev Author: buginator Date: 2010-09-02 05:40:10 + (Thu, 02 Sep 2010) Log Message: --- Trap player to be under MAX_PLAYERS. (looks like player 9 (features) are getting in some routines, and causing crashes.) IdToPointer needs something similar, see http://developer.wz2100.net/ticket/2129. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11525] branches/2.3/src
On Monday, 23 August 2010 at 2:28, bugina...@users.sourceforge.net wrote: Revision: 11525 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=11525view=rev Author: buginator Date: 2010-08-23 02:28:59 + (Mon, 23 Aug 2010) Log Message: --- Remove the template recreation code. (aka 'legs' - r10313 ) Wasn't needed anymore, and I can't think of a good use for the remaining code. Hm, I removed the net message, but the rest looked potentially useful, for things like #1900 for example. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11491] branches/2.3/lib/netplay
On Tuesday, 17 August 2010 at 7:59, Per Inge Mathisen wrote: On Tue, Aug 17, 2010 at 6:19 AM, bugina...@users.sourceforge.net wrote: Add a banned IP list to the game. All people that are kicked will be entered into the file. People using the same IP can *never* enter the game again. All attempts are logged. There is currently a limit of 1000 entries. ** *All entries must be hand edited if you wish to delete them.* ** Isn't this overkill? Someone kicks someone else for fun, or by accident, and does not understand that kicks are forever, will be seriously lost. Also, dynamic IPs. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11426] branches/2.3/po/de.po
On Thursday, 12 August 2010 at 19:51, Christian Ohm wrote: Now we just need someone to be your underling, to see how it works (maybe I'll add another test account for that). I'm not sure how access works, I hope the coordinator can add people, then review their translations and commit them (either through the web interface, or direct commits), and possibly give them commit rights. Hm, looks like underlings also push directly to the repo (and the diffs are horrible, one changed translation, and it reformats a lot of other stuff as well), and the review process is stupid, it offers the complete .po file for download instead of showing only the changed translations... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11426] branches/2.3/po/de.po
On Thursday, 12 August 2010 at 19:09, Kreuvf wrote: So, since you already started that experiment, let's go and see where that leads us. First thing: The FAQ misses yet another question (or it's just me not asking _frequently_ asked questions): With transifex in place can you still edit po files by hand and commit them or are you forced to use whatever solution they decide is best for you (web-based? *shiver*)? It is optional, or I wouldn't have considered it. Well, I registered there, guess the username :P And you're the German coordinator now! Congratulations! Now we just need someone to be your underling, to see how it works (maybe I'll add another test account for that). I'm not sure how access works, I hope the coordinator can add people, then review their translations and commit them (either through the web interface, or direct commits), and possibly give them commit rights. Transifex.net is the main showcase product of Indifex.com. They have a monetary interest in not having it get compromised. The same is true for Flash and Adobe... Well, Adobe is well-known already, and they have other prominent products, like Photoshop. Also, Windows people tend to care less about security issues... When I registered at transifex I wondered why the registration isn't done encrypted. I was glad to see that (at least) signing in is encrypted just to see that after the login things are unencrypted again, changing password, too. Seems their monetary interest in not being compromised isn't that strong... Having user accounts compromised in this case, while earlier you were talking about having the Sourceforge etc. transifex accounts themselves compromised. Though for both I don't see much use for an attacker (but then, I never was interested in hacking stuff), since normal users can't access much more than translations, and if the transifex user does suspicious things, it should become immediately apparent. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11441] branches/2.3/po/de.po
On Thursday, 12 August 2010 at 17:53, kre...@users.sourceforge.net wrote: Updated German translation (+ transifex test to see how it's reacting when changing the po in the repository) The FAQ says they update twice a day, and I at least have an update button to do it manually. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11426] branches/2.3/po/de.po
On Wednesday, 11 August 2010 at 20:23, Kreuvf wrote: Who is transifex? Why does transifex have commit access? More questions: Why do we need this? Because all talk about a private Pootle (or similar) installation fell on deaf ears. Hasn't the benevolent dictator model worked out well? You mean the one person getting more and more annoyed because people can't read and nobody else cares model? Most important question: Why should we trust transifex? Especially since that site is an interesting target (getting commit access to whatever number of repositories transifex has access to) for attackers. It should only ever touch files in po/. As long as it does, I'll trust it. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11426] branches/2.3/po/de.po
On Wednesday, 11 August 2010 at 21:18, Kreuvf wrote: And please don't get me wrong: I am deeply convinced that translations can only be good (aka consistent) as long as there is one maintainer. I've already been through this everybody can edit translations like stupid shit at Launchpad (translation suggestions wouldn't be any better). It just did not work out (apart from the drawbacks of Launchpad): People would just drop in, translate or change some strings (quality doesn't increase necessarily...) and then you may never hear from them again. And in the end the maintainer will just go with the old version. The only thing that causes is more management overhead, so much more that it cannot be justified by the increase in translation quality (if any). Well, it is an experiment currently, to see what it can do. From the looks of it, we can assign a maintainer to each language, who can then add others to work together, and commit stuff. So my management overhead decreases significantly, since I just have to add one person per language, who can then work mostly autonomically. You mean the one person getting more and more annoyed because people can't read and nobody else cares model? Please explain this allusion, because I do not get it. People making the same mistakes again and again, like wrong encoding, starting from another translation, getting the tokens wrong... despite there being a wiki page that (hopefully) explains all that. I'm bad at telling people the same things over and over (well, I can do that, if you don't care about the tone...), and transifex should check at least some of the things automatically. It should only ever touch files in po/. As long as it does, I'll trust it. Of course you cannot trust it anymore, when something different than a file in /po is touched, but that does not give any reason for why to trust it at all. Transifex.net is the main showcase product of Indifex.com. They have a monetary interest in not having it get compromised. Interesting questions: What would be if transifex has been around for a year and people are more or less using it and then such an incident happens? Would you vote for the immediate and permanent ban of transifex? Revoke commit access immediately. If if gets enabled again depends on how they handle it. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3.4
I don't know who put the release date for 2.3.4 in trac to the end of this month - I intend to release it soon, since the burn damage bug is quite severe imo (possibly making the campaign unplayable or at least way more difficult). Objections to tagging later today, release tomorrow? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.4
On Tuesday, 10 August 2010 at 14:28, Per Inge Mathisen wrote: No objections. Perhaps throw in/improve some new maps, if there is time? We could ask if anyone on the forum/irc could add basic/advanced start bases to battle, mischief, cockpit and cockate maps, and include/fix those. Well, I intend 2.3.4 to be basically the real 2.3.3, plus whatever is ready until the release. Though I just remembered that Dydo changed his challenges to use not included maps again (GPLv3, can be downloaded at http://www.obooma.net/dydo/?page_id=935)... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.4
Zn Tuesday, 10 August 2010 at 15:06, Christian Ohm wrote: Though I just remembered that Dydo changed his challenges to use not included maps again (GPLv3, can be downloaded at http://www.obooma.net/dydo/?page_id=935)... Hm, and looking at the maps, they do have some water transition tiles errors, and seem to use features from other tilesets (lots of blue textures in places). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.2 release this weekend ?
On Friday, 23 July 2010 at 15:05, buginator wrote: On 7/22/10, Christian Ohm wrote: Fine by me, probably. As you might have noticed, I've updated the Debian packaging so we can offer .debs, let's see how much feedback that gets. We would then make both tarballs and .debs ? Isn't that what Pabs3 does ? He only makes packages for current Debian. My plan was to offer .debs that work on older systems as well (though until now nobody seems to care, let's see if moving the topic helps). I can build and upload the packages (_fast_, thanks to Fastdeath), so that shouldn't be a problem. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Renaming sequences.wz
On Friday, 23 July 2010 at 14:45, Guangcong Luo wrote: And really zero disadvantages. Except that it'll complicate the code a bit more if we have to look for two extra files. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Renaming sequences.wz
On Friday, 23 July 2010 at 22:10, Rene jochum wrote: There's another disadvantage, users have to findout theier version and rename it, except if you do that in code. Well, I said two extra files, that would search for the new files in addition to the old one. Removing the old name seems like a bad idea to me. Not sure if any distros ship the videos, but if they do, they'd need to reupload the package (or have custom patches to search for the old file), and every user redownload it, just for the name change. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.2 release this weekend ?
On Friday, 23 July 2010 at 22:14, Fastdeath wrote: Would be nice to have packages for different architectures/versions. As example: 1.) Debian Lenny 2.) Debian Etch 3.) Ubuntu Lucid 4.) Ubuntu Karmic Etch? That seems quite old to me... But I think a package built on e.g. Lenny should work on most systems. To be True i don't known howto make them, but i think we/i could create an https://launchpad.net/ account to automaticaly build them? You mean the PPA thing? Looks like that can only build for one version , though both x86 and amd64. Not sure how it would work for us though, since we have the packaging in pkg/dpkg/ and not debian/. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.2 release this weekend ?
On Thursday, 22 July 2010 at 15:23, buginator wrote: Using SF trac, I have come up with these changes so far, I think we should try for a 2.3.2 release this weekend. Fine by me, probably. As you might have noticed, I've updated the Debian packaging so we can offer .debs, let's see how much feedback that gets. Proposed Changelog (so far, I know I have missed some stuff): If you just list the svn messages, let me do it. It's easier to add lines than to look if a change is already mentioned. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] astar.c -- astar.cpp
On Saturday, 3 July 2010 at 11:54, Kreuvf wrote: Cyp wrote: Maybe it would help if the c → cpp conversion was in a separate commit than the rest of the changes? Although it would help, that would make the commit non-atomic and we don't want to do this, right? If the old file compiles as C++, it would be. And yes, I'd prefer separated commits as well if they compile and run. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.1a release and some other comments about the other branches.
On Saturday, 19 June 2010 at 21:53, buginator wrote: For the Qt branch, the only (known) blockers are: 1) No CC builds so we can't test anything our usual way. 2) The lack of full screen resolution switching. 3) Not really a blocker per se, but quesoGLC is back, in case you haven't noticed, and well, it makes it so we can't make MSVC static builds. 4) Videos are very jerky. This has nothing to do with resolution, they are perfectly smooth with SDL. For the codename branch (which is trunk - most recent additions), I think we should make some test builds of that, and throw it out for testing ASAP. We need testing done on trunk, or we will fall into the 2.3 trap once again. Note, we must make builds from a 32bit machine, or we will hit this: http://developer.wz2100.net/ticket/1786 Testing trunk and releasing codename are two different things, since new trunk additions are (currently) not in codename. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] svn/2.3 feature locked status, and what should happen with it
On Tuesday, 22 June 2010 at 19:57, buginator wrote: Currently, I was assuming that 2.3 was feature locked, and we would only be doing bug fixes. However, it has been expressed that the branch shouldn't be feature locked. I especially expressed that it shouldn't be bug fix only, since that would preclude my cleanups for example. Do we make a new branch, which would be the current 2.3 base (and name it something like branch/2.x, delete the current branch/2.3) and continue to work that way (with 2.4, 2.5 and so on), or do we just forget about it being feature locked, and start up with the beta cycles again (with 2.3.2 beta 1?) ? At the moment I don't see any changes that would justify betas, though I want to work on stuff that actually gets released, so I wouldn't want 2.3 to be feature locked. Actually I'm considering to continue with 2.3 even when trunk gets released in some form. Do we take codename (which was trunk, and pretty stable the last time I tried it) and use that as a new base for the next release (3.0 ?) ? Anyone see another way around having all these branches floating around ? A. make a branch only when it's needed, B. finish and merge it back. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10971] branches/2.3
On Tuesday, 15 June 2010 at 14:10, the_cybersph...@users.sourceforge.net wrote: Revision: 10971 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=10971view=rev Author: the_cybersphinx Date: 2010-06-15 14:10:32 + (Tue, 15 Jun 2010) Log Message: --- Display radar unblurred when not rotating. This makes the fixed radar zoom in full pixel steps only, and displays it unblurred. Maximum zoom is increased from 2.5 to 3. Sorry, actually this and r10972 were local patches not meant for committing yet, I forgot about them when updating the changelog... I can revert them, but at least r10972 should be ok. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Music
On Saturday, 12 June 2010 at 16:03, Kreuvf wrote: Reason 1: Download size will increase. And don't tell me this is not an issue. For those doing releases, upload size increases as well, and I usually upload both source and Windows build. So I'm also against including more music in the base game, especially since that'll basically never change. An extra music.wz for those who want more music might be a good idea though. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.1?
Is there any reason not to release 2.3.1 this weekend? The power problem seems at least better than before, I couldn't reproduce the last report (give power to ally). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] File Locations wiki page and new ticket page
I've made a wiki page describing where to find files on the different systems: http://developer.wz2100.net/wiki/FileLocations. Additions and improvements welcome. Also, can we link to http://developer.wz2100.net/wiki/BugReporting from the new ticket page? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] File Locations wiki page and new ticket page
BlueMaxima said mods on Windows go into the program folder, not the config folder. Why? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.1?
On Thursday, 10 June 2010 at 22:58, Per Inge Mathisen wrote: Liked, and at least one other person recommended it: Battle (2p), Pass Assault (2p), mischief (8p), Startup2 (2p, might replace existing Startup). I think we can include any or all of these. Hm, Pass Assault seems to originate from http://worldforceclan.com/warzone2100/maps/New.html... As I just noticed, both Battle and Mischief don't have bases, just HQs. The only of our current maps without full bases are the later added Cockpit and Cockate. Personally I'd not include such maps, but maybe people usually only start without bases... Once ATWb (4p), the Americas map, has been given a license, and maybe some balancing, I think we can include that as well. It is really cool, although probably not (yet) for competitive playing. That one also doesn't have full bases... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.1?
Since noone else proposed any maps, suggestions by just looking at the preview (all from the addons page): 2 player: Arena #22, Battle, Stripmine 4 player: Arena #14 (for Dydo-AI), Garond Valley, Spiral Mountain 8 player: Hamilcar, Mischief ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Adding the Playstation music track (also, do we have lossless versions of the other music?)
On Thursday, 3 June 2010 at 8:50, Kreuvf wrote: Christian Ohm wrote: The question is what to do with the lossless version we need as source, where should that go? SF? SVN? Somewhere else? Are the other music tracks already somewhere in a lossless format? Yes, they are: http://files.kreuvf.de/wz/WZ2100_Premier_Collection_Music.zip http://files.kreuvf.de/wz/WZ2100_Premier_Collection_Music.zip.sig Tell me, when you have it, so I can delete the files. Thanks, I've pulled them to Sourceforge now, where I put the lossless PSX track as well. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Adding the Playstation music track (also, do we have lossless versions of the other music?)
Pabs3 said on IRC that he doesn't see any problems with including the extra track from the Playstation version, so I intend to commit that soon. Relevant IRC log: [10:21] Zarel pabs3: http://developer.wz2100.net/browser/trunk/COPYING.README [10:22] Zarel Would you say this includes media from the PS1 release of Warzone? [10:23] pabs3 its hard to say, but I'm thinking yes because of not included videos and music not being specific about which videos/music [10:23] Zarel Also note dak180's ticket link. [10:23] pabs3 yep, saw that [10:24] Zarel Which establishes that Pumpkin Studios and Edios Interactive do indeed hold the same copyrights to the PS1 release as they do to the PC release. [10:26] pabs3 right, so it is possible/likely the PS1 videos/music are also GPLed [10:27] Zarel So would you say that it is fine to go ahead and use them, given this situation? [10:29] pabs3 unless some complication comes up, yeah I think so [10:30] pabs3 in the long term though, the videos are crap quality-wise and should be replaced with live-rendered stuff or something else [10:30] Zarel Heh, we're talking about the music right now. [10:30] * KukY (~5d8b1...@gateway/web/freenode/x-gryxnubstwldzavw) has joined #warzone2100-dev [10:30] pabs3 the german videos were mentioned before by cybersphinx [10:31] Zarel More specifically, I note that the source code that was distributed contained PS1 code as well as PC code; further confirming that both were released. [10:36] pabs3 thats a useful detail The question is what to do with the lossless version we need as source, where should that go? SF? SVN? Somewhere else? Are the other music tracks already somewhere in a lossless format? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Qt branch - final call
On Monday, 24 May 2010 at 21:34, Christian Ohm wrote: Two problems I've noticed: 1. Video playback is very jerky (SDL is smooth). I got the impression it is worse for the first video when several are played (view intro for example, or the campaign start), but maybe it's just more noticeable in the first one. I've tried now at 1024x768 windowed, and that is smooth... very strange, qt is jerky at 1600x1200 and smooth at 1024x768, SDL always smooth... 2. Fullscreen performance is lower. Not when comparing at the same resolution, but since Qt lacks resolution switching I can't switch to a lower resolution to get higher FPS (e.g. on fast play I get 60 fps with trunk at 1024x768, 30 fps with qt at 1600x1200). Buginator wants it known that he considers this a blocker for the merge. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone documentation
On Wednesday, 19 May 2010 at 18:16, Ben wrote: Just thought I could get your opinions on how I could change this for the better. Zarel; you have your better screenshots, none of that :P Here you go: First, personally I don't like hardcoded HTML tables and stuff, I'd prefer some light markup from which both HTML and PDF can be generated for maintainability. But then, who does the work decides on the tools. - You don't have an index.html as a starting point (in fact, you don't have any html files. DOS is dead, you know). - The logo is screwed up (http://www.abload.de/image.php?img=doc0181ur.png, corrupted file it seems), and scaled in the document (which a. might look worse than using a properly scaled down image, depending on the scaling the browser does, and b. needs useless space). - Centered text looks bad imo, especially with items (http://www.abload.de/image.php?img=doc0261zt.png), I'd prefer justified text. - Interface: see XXX isn't linked (maybe in other places as well). - Minimap: The view area is not always white. - Ordering units: Action and explanation don't always line up (http://www.abload.de/image.php?img=doc03c1yv.png), also there's a quite large gap that makes it a bit hard to see what belongs together. - Why not include the unit experience part as well instead of linking to the website? - The building screenshot is from 2.2, not 2.3. Well, I haven't looked that much at the later parts, just clicked through. My general impression is: The centered text is ugly, the navigation on the left takes up quite a bit of space that might be better used for the content (and with the hardcoded tables is also included when printing, where it is completely useless). But if the centered text (and the small stuff) at least is fixed, I wouldn't mind including it. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3.1?
How about releasing 2.3.1 soon? There have been quite a few commits since 2.3.0, arguably the most important being Dydo-AI's license. Anything that still needs to be done for a release? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.1?
On Tuesday, 18 May 2010 at 21:48, Per Inge Mathisen wrote: On Tue, May 18, 2010 at 9:07 PM, Christian Ohm chr@gmx.net wrote: How about releasing 2.3.1 soon? There have been quite a few commits since 2.3.0, arguably the most important being Dydo-AI's license. If that is the most important thing that has been done, then surely there is no hurry? Well, Pabs said he's waiting for 2.3.1 to upload to Debian, so if you're ok with 2.2.4 for their next release... Anyway, there was other stuff, like making the movie subtitles translatable and translation updates. And it also doesn't seem like there is much else planned for 2.3.1, so what would we be waiting for? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Commit mails for new repositories
On Friday, 14 May 2010 at 19:24, Kreuvf wrote: Is there the possibility to follow commits in a similarly comfortable fashion as is currently done with SVN with the new repositories (be it Hg, git, Bzr or whatever)? I guess once we actually use another repo for actual development we'll set up a commit list for it. But for now, it seems there's not much interest in trying out the various systems. I have to admit, I also don't do much with any of them, committing random crap gets boring fast... If so, please give me some hints at how to set this up. You can use the RSS feeds SF offers, http://warzone2100.hg.sourceforge.net/hgweb/warzone2100/qt_test/rss-log and http://warzone2100.git.sourceforge.net/git/gitweb.cgi?p=warzone2100/test;a=rss. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] git test repo active (also for hg/bzr users)
Since there seems to be no winner in the RCS discussion, we have basically two choices: 1. stay with SVN, 2. Decide on one of them (as backend at least). From what I've read, it seems it is easily possible to access a git repository with both hg and bzr. So I've set up a git repo for testing. The Repository -- The repo can be accessed at git://warzone2100.git.sourceforge.net/gitroot/warzone2100/test (read-only) and ssh://usern...@warzone2100.git.sourceforge.net/gitroot/warzone2100/test (commit access for all SF project members). It was made by importing trunk/tools/editworld into git-svn and is ~ 2 MB currently. The content was chosen somewhat randomly, it is not meant to be useful (as you might note when looking at some of the recent commits), feel free to do (almost) anything to it (except maybe png crushing, so the size stays small for testing). git --- For direct access with git, you obviously need that installed (version 1.6+ I think). Cloning is done with git clone url [folder], this will check out the data into folder (or the repo name test if you don't specify it). Then you do local changes, commit with git commit -a for all changes (check with git diff), or specify file names instead of -a. Pushing back to Sourceforge is done with git push. To create a new branch from the currently checked out revision, do git checkout -b branchname (or git branch branchname; git checkout branchname). This new branch will be in your local repo only, to push it to SF do git push origin branchname (origin is a shortcut for the repo you cloned from, you can also specify another repo there). SSH keys You can create an ssh key so you don't always have to input your password for pushes etc., see https://sourceforge.net/apps/trac/sourceforge/wiki/SSH%20keys#KeyGeneration:OpenSSH. If you already have a key in .ssh, save it to a different file and add that with ssh-add. Then upload the public key (in filename_.pub) to https://sourceforge.net/account/ssh (make sure it stays as one line!). Mercurial on Linux -- Install the hg-git extension and activate it. On Debian, that can be done with apt-get install mercurial-git, and then adding the following to ~/.hgrc: [extensions] hgext.bookmarks = hgext.git = Then you can hg clone the git url, for ssh you need to use git+ssh:// as protocol. Pushing seems a bit slow, though. TortoiseHG on Windows - Download from http://tortoisehg.bitbucket.org/, install with the default options. Then right-click the desktop, choose TortoiseHG-Clone..., enter http://bitbucket.org/durin42/hg-git; as source and C:\hg-git (or where you want it, just adjust the path below then) as destination. This will download the hg-git plugin you need to access git repositories from hg. Then go to Program Files\TortoiseHG and make a new file Mercurial.ini with the following three lines: [extensions] bookmarks = hggit = C:\hg-git\hggit This works for the git:// url, git+ssh:// needs some more setup. First, go to Program Files\TortoiseHg and copy TortoisePlink.exe to ssh.exe. Then download http://the.earth.li/~sgtatham/putty/latest/x86/puttygen.exe, feed your private SSH key into it (see above) and save it in ppk format. Start Pageant.exe from the TortoiseHg folder and import the converted ppk key. After that, cloning works, but pushing/pulling still fails... Could be that I screwed something up while experimenting. Well, that's enough for now. Feel free to experiment with the repo, and report anything regarding needed setup etc., also the bzr part is still untested. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] More on fixing the Qt branch
On Thursday, 29 April 2010 at 22:45, buginator wrote: After some more tinkering with the code, I finally found the issue that MSVC was having. In short, a bool in c is a int, and in c++ a bool !=int. It was always returning 256 on false, and -858993663 on true. For those that don't see what that is, here: false = 0x0100, true = 0xcc01 make sense ? No. Is this another Microsoft stupidity? Evalutating true to 1 and false to 0 seems to be required by the C++ standard (e.g. http://stackoverflow.com/questions/356726/is-bool-a-basic-datatype-in-c). Or is Warzone doing strange things again (that maybe weren't that strange when it was C-only)? If it is a Microsoft problem, I propose switching to the following bool type instead: http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Let's git going
On Wednesday, 28 April 2010 at 18:34, NoName wrote: I do still vote for Mercurial. How about accessing a git repo with hg? http://candidcode.com/2010/01/12/a-guide-to-converting-from-mercurial-hg-to-git-on-a-windows-client/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Let's git going
On Wednesday, 28 April 2010 at 8:58, Per Inge Mathisen wrote: Ok, sorry about the really bad pun. The point is, I think it is about time to leave the barren wastes of svn behind, and head for the promised lands of git. I've been looking into the newline issues, and I am convinced that they can be properly terminated. That leaves only the question of whether git is good/user-friendly enough on Windows/Mac. Given the amount of cross-platform projects that have converted to (g)it, I think we should manage, too. Anyone else have an opinion? I agree. On the line endings, I seem to remember reading somewhere that problems these days are basically only from wrong conversions of existing repos (no source, sorry). So I guess we should a) check all files in SVN (in all branches we still care about) and give them the correct properties, and possibly b) create a new repo with a current git-svn that might do the conversion better than whatever old version was used for the current ones. b) would invalidate all existing git repos, and I'm not sure that step is necessary (but then, it shouldn't be that hard to rebase possible existing branches on the new repo). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10733] branches/2.3/po/de.po
On Tuesday, 27 April 2010 at 20:06, kre...@users.sourceforge.net wrote: Updated German translation, fixed some mistakes (mainly typos) I found during the review of my last commit of 2.3/de.po Why commas after the month in dates? Is that correct in German? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [branches/2.3] configure GLee library has a library, --enable-system-GLee to used system one
On Monday, 26 April 2010 at 12:18, Gilles J. Seguin wrote: wrong, try # cp GLee.h /usr/include/GL # cp libGLee.a /usr/lib64 # ./configure Hm, looking at the GLee source package, the pkg-config file seems to be a Debian addition. Guess we need to add a manual detection for other systems... Actual source code is undocumented hack, over hack, over hack. please, do not stop making the code, more intelligible. I guess we have a differing definition of intelligibility then, I don't think heaps of ifdefs increase it. Accept the patch as it is No. On my system, GLee.h is in /usr/include, so your patch would break that. and remove GLee.h That is, you were suppose to make it wright on first pass. Not adding another hack read again, configure GLee library has a library that is, i want to test with the real thing the header for GLew are included has #include GL/glew.h What exactly is the hack (or hacks?) here? We include a GLee.h, either the included one or from the system, and the same for the library. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Debian and warzone2100 2.3.0 issues (Dydo-AI etc)
On Sunday, 25 April 2010 at 14:58, Paul Wise wrote: Also the embedded miniupnpc and iniparser copies are missing their LICENSE files. For iniparser, this is a license violation. For miniupnpc it is less of an issue because some of the files contain a copy of the license. For miniupnpc, I've included what was in the tarball, seems like the author didn't include a separate license file. In future, I'd really really prefer that you add stuff to devpkg instead of adding embedded code copies like iniparser, miniupnpc, GLee, sqlite and parts of others like BFD, SDL_framerate. autoconf macros are usually OK as long as you don't store them in SVN but get them by running autoreconf. I think sqlite when it was used was needed some specific version, so that was included. miniupnpc wasn't in Debian at least, and since we don't use Linux devpackages I included that (and the alternative upnp libraries sucked for various reasons), glee was the same I think. Generally I also prefer external libs, but then we need someone to update all our buildsystems/devpackages. I can do the autoconf stuff, maybe the Windows cross-build, that leaves at least three other systems (Mac, MSVC, the mingw32 makefiles), which all need to be apapted to the new stuff (with new devpackages etc.). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Debian and warzone2100 2.3.0 issues (Dydo-AI etc)
On Sunday, 25 April 2010 at 21:52, Paul Wise wrote: The latest version (1.4) does include one. Which version did you include? http://developer.wz2100.net/browser/tags/2.3.0/lib/netplay/miniupnpc says the license file is included, but maybe it's missing from the tarball. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [branches/2.3] po/fr.po
On Sunday, 25 April 2010 at 11:34, Gilles J. Seguin wrote: #: src/multijoin.c:228 #, c-format msgid File transfer has been aborted for %d. -msgstr +msgstr File transfer has been aborted for %d. #: src/multilimit.c:316 msgid Limits reset to default values -msgstr +msgstr Limits reset to default values #: src/multiplay.c:1097 msgid [invalid] -msgstr +msgstr [invalid] Why do you use the English term as translation in those (and quite a few others)? That makes it difficult to find untranslated strings, and if you don't want to translate them you can just keep them empty. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [branches/2.3] configure GLee library has a library, --enable-system-GLee to used system one
On Sunday, 25 April 2010 at 12:11, Gilles J. Seguin wrote: - create --enable-system-GLee option to used system GLee library and header What's wrong with the current way? When GLee is installed on the system, it uses that, else the integrated copy. - new macro MZ_HAVE_GLEE to select between includes GLee.h and GL/GLee.h Ehm, no? Why would we want to litter our code with ifdefs if we have autoconf to sort it out? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Proposed patches for tags/2.3.0
New one: http://developer.wz2100.net/changeset/10694 Tested by pabs3, and I guess he'll include it in the Debian package if we don't commit it. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10607] branches/2.3/data/mods/multiplay/dydo-ai
On Saturday, 17 April 2010 at 15:31, Per Inge Mathisen wrote: On Sat, Apr 17, 2010 at 3:11 PM, dydo...@users.sourceforge.net wrote: maps for dydo challenges Added Paths: --- branches/2.3/data/mods/multiplay/dydo-ai/maps/ branches/2.3/data/mods/multiplay/dydo-ai/maps/4c-AllEqual.wz branches/2.3/data/mods/multiplay/dydo-ai/maps/4c-Arena_14.wz branches/2.3/data/mods/multiplay/dydo-ai/maps/CNCAssualt.wz Who made these maps? And for some more questions: Why are they in .wz format? If they're included in the game, people will have them anyway, so they can be uncompressed. Also, why not put them in the main data, so they can be used for all types of games (that goes for the maps in ntw as well)? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10607] branches/2.3/data/mods/multiplay/dydo-ai
On Saturday, 17 April 2010 at 15:31, Per Inge Mathisen wrote: On Sat, Apr 17, 2010 at 3:11 PM, dydo...@users.sourceforge.net wrote: maps for dydo challenges branches/2.3/data/mods/multiplay/dydo-ai/maps/4c-AllEqual.wz branches/2.3/data/mods/multiplay/dydo-ai/maps/4c-Arena_14.wz branches/2.3/data/mods/multiplay/dydo-ai/maps/CNCAssualt.wz Who made these maps? AllEqual seems to be a converted map for the original game, couldn't find out who made it. Arena #14 is by Olrox, http://forums.wz2100.net/viewtopic.php?f=10t=4875 CNCAssualt by DraLUSAD, http://forums.wz2100.net/viewtopic.php?f=10t=4799 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3 code freeze until 2.3.0 branch, 2.3.0 release target date 4/24/10
On Saturday, 17 April 2010 at 15:45, buginator wrote: Let's try this again, 2.3 is in a code freeze, and ONLY show stopping bugs will be fixed. It was suggested that we branch 2.3.0 from svn head, once we know the status of the Dydo changes. Actually, I'd branch 2.3.0 from the rc tag as soon as possible, since the whole point of branching is that the 2.3 branch then is not frozen, only the 2.3.0 branch (which then can get selected backports from 2.3). Zarel proposed a tag instead of a branch for 2.3.0, to which we commit until the final release. Doesn't matter much to me, it's all the same anyway in svn. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Getting the word out about 2.3.0 ?
On Saturday, 17 April 2010 at 20:24, buginator wrote: So far, the list is: http://linuxgames.com/ http://happypenguin.org/ http://linux-gamers.net/ http://freshmeat.net/projects/warzone2100/ We could also announce the RC on those sites, to get it a bit more exposed (though we'd need at least a rough changelog since 2.2 for that). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3 RC 1a to tag on 4/16 or 4/17
On Tuesday, 13 April 2010 at 22:14, buginator wrote: Barring any other showstopping bugs, or objections, I think we should tag 2.3 RC1a late Friday night or early Saturday morning to get this out to as many of our current testers as possible before they start their weekend gaming sessions. All mod authors, please make whatever changes you need to make ASAP. Any other NON bug fixes should NOT be in 2.3, you missed the boat. Did I miss anything? http://developer.wz2100.net/ticket/251 If we can find a nice way to test if we're loading a game (game time if that works, or something else), this should be included I tink. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3 RC 1a to tag on 4/16 or 4/17
On Tuesday, 13 April 2010 at 22:14, buginator wrote: Barring any other showstopping bugs, or objections, I think we should tag 2.3 RC1a late Friday night or early Saturday morning to get this out to as many of our current testers as possible before they start their weekend gaming sessions. All mod authors, please make whatever changes you need to make ASAP. Any other NON bug fixes should NOT be in 2.3, you missed the boat. Did I miss anything? I've got the Playstation music track now (in its original 37800 Hz), and could add the Vorbis version (upsampled to 44100 Hz of course) to the music folder. Any objections? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Ticket #1746
On Thursday, 8 April 2010 at 23:36, Per Inge Mathisen wrote: On Thu, Apr 8, 2010 at 3:03 PM, Christian Ohm chr@gmx.net wrote: But it still breaks loading new saves in older versions? Why do we need that? To see if a campaign problem also happens in older versions? But if that is already broken, as Zarel says, breaking again won't hurt much. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Ticket #1746
On Wednesday, 7 April 2010 at 18:54, Guangcong Luo wrote: On Wed, Apr 7, 2010 at 6:22 PM, Christian Ohm chr@gmx.net wrote: In this case... Well, looking at the patch, you increase the savegame version. Does that break campaign saves (I'd guess it would, if it works for campaign mods)? If yes, do we really want that break between 2.3.0 and 2.3.1? ...erm, are you sure you're looking at the right patch? Notice this line: -return deserializeSaveGameV35Data(fileHandle, (SAVE_GAME_V35*) serializeGame); +return deserializeSaveGameV38Data(fileHandle, (SAVE_GAME_V38*) serializeGame); The thing is, we have a different savegame loading function for each savegame version, so we don't lose savegame compatibility. The ticket description also says: This patch bumps the savegame version to 38. It adds mod information to the save game. When loading earlier savegames, it will simply won't replace the loaded mods with the mods in the savegame. In other words: This patch does not break savegame compatibility. Did you mean to say that 2.3.0 would no longer be able to load 2.3.1 saves? Yes. That's what the new version means, right? And I thought we avoided doing that for campaign saves for a long time now. This whole exercise is moot, though, since Per's preferred solution is to commit the savegame changes, but just don't do anything with the new saved data in 2.3.0. But it still breaks loading new saves in older versions? Couldn't we add a new file for additional info, so the basic savegame can still be loaded in older versions? Keeping the campaign working seems difficult enough without not being able to test stuff in old versions... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Branching 2.3.1
On Wednesday, 7 April 2010 at 14:25, Guangcong Luo wrote: There's been a lot of drama surrounding what should and shouldn't be committed to 2.3-branch. The things we are postponing to 2.3.1 are things that deserve testing, and I believe the sooner we get them tested, the better. I think there's a simple solution we should consider: I propose we create 2.3.1-branch now. Objection. _If_ something is branched off, it should be 2.3.0. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Ticket #1746
On Wednesday, 7 April 2010 at 13:59, Guangcong Luo wrote: On Wed, Apr 7, 2010 at 11:46 AM, Per Inge Mathisen per.mathi...@gmail.com wrote: I do not like how this kind of heated rhetoric appears again and again every time we try to say no to a change you want pushed into a release immediately. Okay, I'll try to be calmer, but you can't just ignore my point because of the way I said it. The reason why I do so is because I am frustrated that no one has provided an adequate response to these questions, so from my point of view we are withholding my fix without adequate reasons. Well, there were times you turned up when someone wanted to tag a release with stuff that absolutely had to go in now which noone had even seen before (and I don't think that stuff turned up in trunk to be maybe considered for the next beta, but the process started again then...). Doing that is just bad practice (as was mentioned before occasionally, which might be the reason these debates get a somewhat harsh tone these days), betas are not for testing completely new code, but code that has been alpha-tested already, in our case by having been in SVN for a while. In this case... Well, looking at the patch, you increase the savegame version. Does that break campaign saves (I'd guess it would, if it works for campaign mods)? If yes, do we really want that break between 2.3.0 and 2.3.1? So why are we at beta 12 then? Because someone has made the decision to release those betas? Namely me, in case of beta 4-9. Beta 4 was overdue, 5-9 followed ~ weekly, always after obvious problems in the older betas were fixed. After beta 9, the big problems didn't get fixed as fast, so next ones were at a slower pace again. How many betas we have and how stable the codebase is are only vaguely correlated (which is why I am frustrated whenever the number of betas - a complete non-sequitur from my point of view - is brought up as the reason for refusing to commit a fix). I have to agree here - had we continued at Buginator's pace, we'd be at beta 7 maybe, with my pace somewhere around 20. You know why, every once in a while, I slip up and say you instead of we when referring to the team? It's because each time I've disagreed with another team member, we've gone with the other team member's wishes. It's difficult to feel like part of a team when one feels completely ignored. That works two ways - at times it seems like you keep talking until everyone else is tired of talking back, and you take that as agreement. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
