Am Dienstag, 17. Juni 2008 06:57:28 schrieb bugs buggy: > On 6/16/08, Per Inge Mathisen <[EMAIL PROTECTED]> wrote: > > After some discussion, I would like to soften the suggestion a bit: > > > > Commit guidelines: > > 1) All larger patches should go into the patch tracker. Give people > > time to comment on it. Add yourself to the cc: list of patches you are > > interested in. > > 2) Try to break up larger changes into smaller patches when possible. > > 3) Do not mix unrelated cleanup and feature changes or bug fixes in > > the same patch. > > 4) Fix the coding style of lines you edit, but try to avoid doing that > > to any other lines. > > 5) Be very careful about cleaning up code that other people may be > > working on. > > > > I would like to emphasise the last point. It is very demotivating to > > see someone else's quick cleanup work rip asunder the careful > > rewriting you've been carrying on over several months to some part of > > the codebase, but not yet committed. > > > > - Per > > Most of that sounds good (in theory), guess we will see how it holds > up in practice. :) > I would also like to add, *test* your patch, and if you can't, then > please let others know. > > What do I mean by testing your patch? I know that most people test > their patches in some form, but, warzone is pretty complex, in how > everything works with everything else. > A) We have multiple platforms. We must take care to make something > work on all platforms. (Be it not using C99 coding, endian, build > system or whatever else. I know it isn't always possible/people > forget, or people might not have the know how, but keep this in mind). > 1) It might be very hard to get the OK on windows & linux & macs > before the 48h period expires--especially the mac, since we lack > people using them. It would be cool if we were able to build up a tester staff. Chojun said they were having a good QA team for wz22, so maybe we could share a few of them for the Windows platform?
Automated unittests might help a little bit here too. > B) We have SP, MP, and Skirmish. > 1) for SP, we have multiple code paths depending on what is going on, > from offworld missions, to datasets changing, to them not changing, to > a mission inside another mission, and so on. This is perhaps the > hardest thing to test, since we have so many different variables > involved. (And try NOT to use cheats like the 'give all' or 'get off > my land' ones) I doubt I will play through the whole campaign to test i.e. my projectile rewrite. See: I never finished the campaign before, and I am not really a good player either, so it could take me weeks to complete the testing alone... > 2) for MP & Skirmish (yes, there is a difference--depending on what > your changing), we have multiple maps, and multiple tech levels. Also > have multiple players & multiple AIs involved. Usually, if it works > on 8p games, then it should work on 2p & 4p games. For maps, we have > all sorts of sizes involved, and certain maps are better for testing > certain things than others. (ie, flat maps vs non flat maps, 'maze' > type maps vs wide open maps). We could add a random-map feature accessible from the commandline. This might encourage testing a wider range of maps, since currently I just quickly click through the screens to check Sk-Rush... > C) For specific tests, like AI, rendering, pathing, whatever else, we > need to come up with a better way of testing, since things are > slipping through the crack. I am not ever sure a 48h period would be > enough to test some of these things fully. I tried adding unittest to the projectile system. Due to the quirky way everything depends on everything in WZ, this proved ... difficult. I instead just copied the relevant function out of projectile.c. Though this works for initial testing and tweaking, this is obviously not good enough for a unittest. The important part about this was that the unittests could be run without starting full-blown warzone, and that they can be run independendly, i.e. on buildtime. If someone has a good idea how to achieve this, would be nice. > The twist in the bucket is, even with 96h in the tracker, we still > might not catch bugs that the community will catch. Nightly builds > are very helpful (and should be archived IMO--so we can narrow down > bugs quickly) > They also need to have a more prominent spot, so people can help us > find issues quicker. I dunno, we could make a contest, to see who can > find the most bugs, and the winner gets a feature they want put into > warzone at a higher priority than all the other feature requests? Sounds like a nice thing. Though I would like to reduce the bugcount before that, so it becomes interesting. ;) What about doing this slightly after 2.1.0? > And *all* testing/nightly builds need to be debug builds. Release > builds could also be made, but if space is tight, I prefer debug > builds. Due to the optimizations being done in release builds, they may have bugs which are not present in debug builds (aliasing of type-punned pointers anyone?). So they need a little bit testing, too. --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
