Development process ------------------- :doc:`Read this overview ` of how to use Git with ``scikits.image``. Here's the long and short of it: * Go to `http://github.com/stefanv/scikits.image `_ and follow the instructions on making your own fork. * Create a new branch for the feature you want to work on. Since the branch name will appear in the merge message, use a sensible name such as 'stefan-transform-speedups'. * Commit locally as you progress. * Push your changes back to github. * Ping Stefan to request a merge into the main development branch (or simply click on "Request Pull" in GitHub). You may also read this summary by Fernando Perez of the IPython project on how they manage to keep review overhead to a minimum: http://mail.scipy.org/pipermail/ipython-dev/2010-October/006746.html .. note:: Do *not* merge the main branch into yours. You may rebase, as long as you are `aware of its dangers `_ (also see `LWN article `_). * To reviewers: add a short explanation of what a branch did to the merge message or, if closing a bug, add "Closes gh-XXXX". Guidelines `````````` * All code should have tests (see "Test coverage" below for more details). * All code should be documented, to the same `standard `_ as NumPy and SciPy. * Follow the `Python PEPs `_ where possible. * No major changes should be committed without review. Ask on the `mailing list `_ if you get no response to your pull request. Test coverage ````````````` Tests for a module should ideally cover all code in that module, i.e. statement coverage should be at 100%. To measure the test coverage, install ``_ and then run:: $ make coverage This will print a report with one line for each file in `scikits.image`, detailing the test coverage:: Name Stmts Exec Cover Missing ------------------------------------------------------------------------------ scikits/image/color/colorconv 77 77 100% scikits/image/filter/__init__ 1 1 100% ... Bugs ```` Please `report bugs on Github `_.