Hi! We've worked out a plan how to get the netcode fastly into WZ. Fred is missing time a bit, that's why I write this mail.
The plan is this: 1. The netcode patch ( https://gna.org/patch/?772 ) needs to be split up in function (recieve/send) pairs. 2. People (at least 2) apply one such pair at a time. 3. They play and test it, reporting any issues they find. 4. When they can't find any issues with a patch after thorough testing, they approve it as working. 5. They grab the next patch and start at (2). 6. Somewhere in between or thereafter the approved patches are commited. 7. We arrive at a stable netcode for everyone! To coordinate the testing I propose to create a Wiki page, eg. http://wiki.wz2100.net/Netcode_festival where all the patches are listed and people can make comments, approve them, etc. The plan, advice, etc. should be copied there for further reference... Notes: 1. These patches need to be SVN created patches, since TortoiseSVN refuses to apply others, which would mean we would loose lots of Windows testers! 2. At least 2 people need to test one pair patch and these patches cannot be intermixed. So people who have applied patch1 cannot test together with people who have applied patch2. People providing binaries per patch are of course welcome. 3. Playing an hour or 2 should be enough (depends on type of patch). What is to be tested is related to the part the patch affects. I.e. if you test a patch related to unit-movement, you obviously don't need to build a lot of buildings... What parts are affected by each patch should be summarized on the wiki page, possibly along with a list of proposed testing procedures. 2.-5. Happen in parallel, so that we get maximum speed. (If the resources are present, which I hope is the case. If they are not it doesn't matter anyway.) 6. Commiting the patches after testing has finished has the benefit that if some bug was overlooked, it doesn't cause confusion for other patch-testers as to why exactly the vtol-rearm patch breaks research-facilities (eg). 7. And, of course, world domination. I strongly advise to run the game in a debugger for the whole time. Otherwise it might get difficult to create backtraces in case they are needed. Being connected via realtime chat (eg. IRC) could help in case of problems, but of course this is not required to participate. Any feedback needs to contain at least this: - Operating system (Windows, Linux, MacOSX, ...) and architecture (x86, x86_64, ppc, ppc64, ...) of the involved systems. (Important! This is where the old code failed.) - Additional info, like "Windows XP SP2", "Ubuntu 7.10", "MacOSX 10.4" and whatever seems useful. - In case of crashes a backtrace. (If all else fails the crashdump _and_ the binary might work as well...) - A detailed problem description, i.e.: -- What was done before the issue happend? -- What should have happened? -- What happened instead? -- How can it be reproduced? I hope we get this done soon, Dennis
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
