dak

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