[IPython-dev] A simple patch policy for IPython contributions

[Fernando Perez]

Hi everyone,

as ipython's userbase grows, more and more people are sending me patches.  I
greatly appreciate this, and I hope the process continues.  However, more
patches mean more alien code for me to study, so I want to specify a minimal
'policy' on patch creation to try and make the process as smooth as possible.

This is just a set of simple guidelines aimed at ensuring that we all spend
our limited time on the code itself and not struggling with patch management.
I've said some of this before, but I want it in a separate message for easy
reference and archiving.

I don't want to sound patronizing or to anger anyone, it's just a matter of
making the process as simple and efficient as possible to all involved (with
my time counting double or triple, because I am the bottleneck).  Any comments
on this are very much welcome (except for any discussion on #1).

Ipython's minimal patch policy:

1. ***NEVER, EVER, EVER*** USE HARD TABS.  USE 4 SPACES FOR INDENTATION.

    I want to make sure that this one is as loudly and clearly spelled out as
    possible.  It is absolutely not open to discussion.  I've already had bugs
    creep in because of patches with hard tabs in them, so in the future I'll
    simply reject any patch with a single tab in it.

    IPython is indented (following python.org policy) with 4 spaces per level.

2. Please send patches as attachments, with a .diff extension.

    This way, there are no issues with manual copy/pasting from a mail client's
    window.  And they load them into XEmacs with syntax highlighting.

3. Make your patches against current CVS.

4. Use -u in diff, I find unified patches easier to visually parse.

That's it.

For those interested in more info about contributing to an open source
project, Here are some links I've found.  They are probably no better or worse
than other similar documents:

http://www.linux.com/howtos/Software-Release-Practice-HOWTO/index.shtml
http://www.kegel.com/academy/opensource.html

Best regards, and thanks again to all who have contributed in the past.

Fernando.