From 2edf9af0cc2d64eafbc4a98222e1288ce4536281 Mon Sep 17 00:00:00 2001 From: Joerg Jaspert Date: Wed, 31 Dec 2008 11:45:41 +0100 Subject: [PATCH] Remove ChangeLog, add README.coding Removed the ChangeLog, from now on we go with the git commit messages. One source less for merge conflicts. Also added a README.coding, mostly a copy from dakV2. I very much love to get code from others, so to not annoy new committers too much, lets go and write the basic rules I try to apply down here. Better than nagging after I got a patch to merge. Signed-off-by: Joerg Jaspert --- ChangeLog => ChangeLog.old | 0 README.coding | 72 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 72 insertions(+) rename ChangeLog => ChangeLog.old (100%) create mode 100644 README.coding diff --git a/ChangeLog b/ChangeLog.old similarity index 100% rename from ChangeLog rename to ChangeLog.old diff --git a/README.coding b/README.coding new file mode 100644 index 00000000..bbe24172 --- /dev/null +++ b/README.coding @@ -0,0 +1,72 @@ +Some small guidelines if you want to help coding +------------------------------------------------ + +First: I'm always happy to get patches for Dak. I like to merge +enhancements, bugfixes, whatever. The more, the better. + +Now, to not annoy us all by coming up with small fixes to patches +multiple times before I merge them, lets write down a few small +guidelines we all should follow. Yes, the current dakV1 code sure won't +follow this everywhere, but no need to have new code be the same. :) + +I very much prefer git trees to merge from over simple patches, +especially if you do lots of changes. (No need for a full git tree for a +one-off fix). Reason is simple - its much easier to work with. And it is +also way better in terms of assigning who did what, who has to earn the +praise. :) +In case you have more than one feature you want me to merge, one branch +per feature please. If the location of your git tree is stable and +doesn't change every second day I'm also very grateful. :) + + +Code related: + +- Use readable and self-speaking variable names. + +- Its 4 spaces per indentation. No tab. + +- You want to make sure to not add useless whitespaces. If your editor + doesn't hilight them, Git can help you with that, just set + [color "diff"] + new = green + old = red + frag = yellow + meta = cyan + commit = normal + in your ~/.gitconfig, and a git diff should hilight them. + Even better, if you enable the hook pre-commit in your copy of the dak + code (chmod +x most probably), git will refuse to commit such things. + +- Describe *every* function you write using a docstring. No matter how small. + +- Also describe every file. + +- Don't forget the Copyright/License header in a file. We expect GPLv2 :) + +- Don't write long functions. If it goes above a sane limit (like 50 + lines) - split it up. + +- Look at / read http://www.python.org/dev/peps/pep-0008/ + + +VCS related: + +- History rewriting is considered bad. + +- Always have a "Signed-off-by" line in your commit. `git commit -s` + automatically does it for you. Alternatively you can enable the hook + "prepare-commit-msg, that should also do it for you. + +- Write good, meaningful, commit messages. We do not have a Changelog + file anymore, the git commit is *the* place to tell others what you + did. + Also, try to use the standard format used in the Git world: + + First comes a summary line, of around 72 caracters at most. + + Then, a blank line, and as many lines and paragraphs as needed + to describe the change in detail. Beware, though, of including + in the commit message explanations that would be better to have + as comments in the code itself! + + Signed-off-by: Your Name -- 2.39.5