Maintainers
MDP has been originally written by Pietro Berkes and Tiziano Zito
at the Institute for Theoretical Biology
of the Humboldt University, Berlin in 2003.
Current maintainers are:
Yaroslav Halchenko maintains the python-mdp Debian package,
Maximilian Nickel maintains the py25-mdp-toolkit and py26-mdp-toolkit MacPorts packages.
MDP is open to user contributions. Users have already contributed some
of the nodes, and more contributions are currently being reviewed for
inclusion in future releases of the package. The package development
can be followed online on the public git code repositories or
cloned with:
git clone git://github.com/mdp-toolkit/mdp-toolkit.git
git clone git://github.com/mdp-toolkit/mdp-docs.git
For comments, patches, feature requests, support requests, and bug reports
you can use the users’ mailing list.
If you want to contribute some code or a new algorithm, please do not
hesitate to submit it!
Development process
Development takes place on the master branch, but it doesn’t mean
that everything should be immediately commited there.
Small commits and bugfixes and the like should go immediately on the
main branch, if the commiter thinks that nothing will be broken by the
patch:
git checkout master
# make a small fix :)
sed -ir s/develepement/development/g development_process.rst
git add development_process.rst
git commit -m 'FIX: correct spelling of development'
More complicated commits should go on a feature branch:
git checkout -b my_new_feature
<do some changes>
git add <some-file> <some-other-file>
git commit -m 'NEW: add subfeature-1'
<do some more changes>
git commit -m 'NEW: implement this and that'
When a developer wants to show the branch to other people, she should
push it into the main repo:
git push origin my_new_feature
Temporary branches
If you are about to test something and you’ve got the idea that your
code won’t last long in the repository, (maybe you want to show your
code to another developer or you want to just check, if you can commit
to the server,) you should create another branch for that, the same as
for any new feature.
The advantage is, that it keeps our master branch clean from all those
‘testing some really strange new stuff – please have a look’ commits,
which are likely to be reverted again. When you feel good about your
commit, you can cherry-pick or merge the good stuff to master.
Alternatively, ‘please have a look’ commits may also be pushed to a
separate repository (e.g. a github fork).
Merging feature branches back into the master branch
Development is consensus based, so new features should be posted for
review and gain acceptance before being merged back into the main
branch. After the decision to merge has been made:
Check that all tests pass on the feature branch. Ideally, the branch
should already include tests for all code it introduces or
significantly changes.
Some things to test in special circumstances:
If the code does anything version specific, it should be tested on
all supported python versions:
python2.5 /usr/bin/py.test
python2.6 /usr/bin/py.test
python2.7 /usr/bin/py.test
python3.1 setup.py build
(cd build/py3k && py.test-3.1)
(cd build/py3k && python3.2 /usr/bin/py.test-3.1)
TODO: add windows and mac equivalents
If the code does anything platform specific if should also be
tested on Windows.
Code should be tested with both numpy and scipy as backends.
Since scipy will be selected by default if installed, the extra
step that can be performed is testing while selecting numpy
explicitely:
Before merging also make sure that the master branch passes tests :)
The merge should be performed in a way that preserves the history
of the branch:
git checkout master
git merge --no-ff my_new_feature
The merge commit should retain the name of the branch in the
message. E.g. a commit with a message Merge branch my_new_feature
is OK, commit with a message
Merge commit 1234567890123456789012345678901234567890 is not so good.
After merging, tests should also pass.
If tests fail and the failures are caused by a problem with the
merge, the merge commit should be amended:
<fix code>
py.test ...
git commit --amend -a
If the changes introduced in the branch simply uncovered problems in
other parts of the codebase, the fixes can be committed as separate
changesets.
Only when tests after the merge execute satisfactorily, changes
should be pushed to sourceforge. The old branch can be deleted.:
git push origin :my_new_feature
Git commit messages
Commit messages are supposed to start with a prefix that specifies the
type of change:
- DOC: documentation
- FIX: fixes something
- ERF: enhancement, refactoring
- NEW: a new feature
- OTH: other (use with care)
The message should consist of a short summary (up to about 70
characters) and a longer explanation after an empty line. The summary
messages will are used to generate a changelog for distribution
tarballs.
History rewriting
The developer that created a feature branch is free to rewrite the
history of the branch if she finds it reasonable:
# do some history cleaning
git rebase -i $(git merge-base origin/master my_new_feature)
# upload a new version of the branch and override the old one
git push --force origin my_new_feature
If multiple developers wants to cooperate on feature_branch, they
should agree between themselves on a history rewriting policy.