##// END OF EJS Templates
testing fixes
testing fixes

File last commit:

r2599:aa4014be
r3641:4f574e16
Show More
contributing.txt
52 lines | 2.2 KiB | text/plain | TextLexer
Brian Granger
Major work on the documentation....
r2277 .. _contributing:
============================
Brian Granger
Work on documentation....
r2276 How to contribute to IPython
============================
Brian Granger
Major work on the documentation....
r2277 Overview
========
Fernando Perez
Add Git workflow docs from Gitwash....
r2599 IPython development is done using Git [Git]_ and Github.com [Github.com]_.
Brian Granger
Work on documentation....
r2276 This makes it easy for people to contribute to the development of IPython.
There are several ways in which you can join in.
Brian Granger
Major work on the documentation....
r2277 Merging a branch into trunk
===========================
Brian Granger
Work on documentation....
r2276
Core developers, who ultimately merge any approved branch (from themselves,
another developer, or any third-party contribution) will typically use
Fernando Perez
Add Git workflow docs from Gitwash....
r2599 :command:`git merge` to merge the branch into the trunk and push it to the main
Git repository. There are a number of things to keep in mind when doing this,
so that the project history is easy to understand in the long run, and that
generating release notes is as painless and accurate as possible.
Brian Granger
Work on documentation....
r2276
Brian Granger
Major work on the documentation....
r2277 * When you merge any non-trivial functionality (from one small bug fix to a
big feature branch), please remember to always edit the appropriate file in
the :ref:`What's new <whatsnew_index>` section of our documentation.
Ideally, the author of the branch should provide this content when they
submit the branch for review. But if they don't it is the responsibility of
the developer doing the merge to add this information.
* When merges are done, the practice of putting a summary commit message in
the merge is *extremely* useful. It is probably easiest if you simply use
the same list of changes that were added to the :ref:`What's new
<whatsnew_index>` section of the documentation.
* It's important that we remember to always credit who gave us something if
Brian Granger
Work on documentation....
r2276 it's not the committer. In general, we have been fairly good on this front,
this is just a reminder to keep things up. As a note, if you are ever
committing something that is completely (or almost so) a third-party
contribution, do the commit as::
Brian Granger
Major work on the documentation....
r2277
Fernando Perez
Add Git workflow docs from Gitwash....
r2599 $ git commit --author="Someone Else"
Brian Granger
Work on documentation....
r2276
This way it will show that name separately in the log, which makes it even
easier to spot. Obviously we often rework third party contributions
Fernando Perez
Add Git workflow docs from Gitwash....
r2599 extensively ,but this is still good to keep in mind for cases when we don't
Brian Granger
Major work on the documentation....
r2277 touch the code too much.
Fernando Perez
Add Git workflow docs from Gitwash....
r2599 .. [Git] The Git version control system.
.. [Github.com] Github.com. http://github.com