Am Freitag, 14. Dezember 2007 01:38:59 schrieb Dennis Schridde: > 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? Ok... This seems to be a very actively discussed topic, which is interesting to lots of people it seems... [/irony]
We should make the patch splitting a HIGH-PRIORITY task, really. After that also non-coders can start to test it. So the work needed from our part is not really *that* much... Everyone with 5 minutes of free time, please have a look at https://gna.org/patch/?772 , pick one function pair, make it apply to current HEAD and send it back... I am already lagging behind with my homework, but I'll allocate my friday-evening to this, though I hope there is not much left of the patch by then. ;) --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
