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. 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) 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). 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. 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? 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. Just think, I was only going to say 'ditto' before all this. :p _______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
