Am Montag, 16. Juni 2008 21:47:16 schrieb Giel van Schijndel: > Per Inge Mathisen schreef: > > On Mon, Jun 16, 2008 at 9:21 PM, Giel van Schijndel <[EMAIL PROTECTED]> > > wrote: > >> Per Inge Mathisen schreef: > >>> Here is what I would like to see: > >>> 1) Every patch goes into the patch tracker. Give a quick run down of > >>> what it does and what it changes. > >>> 2) After a patch has been put into the patch tracker, give this list > >>> 48 hours to comment on it. Exception for patches that *only* fixes > >>> bugs that makes the game unplayabled or fixes build errors. > > > > ... > > > >> Actually, I'm not even sure that I even *want* to see big patches > >> getting done really. I'd much rather see changes being committed as > >> several smaller patches, thus increasing their granularity and making > >> them easier to be understood by others. > > > > Well pointed out. I would add these points then: > > 3) Try to break up larger changes into smaller patches when possible. > > 4) Do not mix unrelated cleanup and feature changes or bug fixes in > > the same patch. > > 5) Fix the coding style of lines you edit, but not that of any other > > lines. > > Actually I'd rephrase 5 to something like this: > 5) Fix the coding style of lines you edit and the single function > surrounding these lines, not that of other lines, and commit the coding > style changes _separately_ from the non-style changes. Seems you want to reduce the commitrate to one per year? I'm fine with it, I have a local repo. :)
This is what I'd propose: 1) I somewhat prefer mails. Seems easier to me than dumping patches into files, firing up a webbrowser, logging into Gna, ... 2) 48h seems ok, exception for small patches too. 3) Try to splitup sounds good too. What I did lately is to i.e. merge cleanup patches when the you could distinguish them from each other (i.e. seperate files). 4) Seems cumbersome to me, since when I try to fix a bug, some cleanup will almost always sneak in, and additionaly I first cleanup and understand a function, and then fix it (sometimes it is already fixed by the cleanup). I would have to do a lot of surgery... 5) Especially because of 4 this seems cumbersome, too. Apart from that I dont think it matters a lot where your brackets are placed or whatever. I'd say "make it readable, for others too, and if you feel responsible for something or are redoing it anyway just do what you think fits". If you create a new commit for every style change, the work you do will be at least doubled (you've got to parse through the function 2 times at least, while you have to hold yourself back to not fix anything in the first run). Doesn't sound stunning to me. --Dennis
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
