You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Explain what the expected behavior was, and what you saw instead.
36
24
37
25
#### Pull Requests
38
26
39
-
-**Make sure the test suite passes** for both python2 and python3.
40
-
You can use `test_fast.sh`, **tox** locally, and/or enable **Travis-CI** on your fork.
41
-
See "Getting Travis-CI going" below.
27
+
-**Make sure the test suite passes** on your box, Use the provided `test_*.sh` scripts or tox.
28
+
- Enable [Travis-Ci](http://travis-ci.org/pydata/pandas). See "Getting Travis-CI going" below.
29
+
- Use [proper commit messages](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html):
30
+
- a subject line with `< 80` chars.
31
+
- One blank line.
32
+
- Optionally, a commit message body.
33
+
- Please reference relevant Github issues in your commit message using `GH1234`
34
+
or `#1234`. Either style is fine but the '#' style generates nose when your rebase your PR.
35
+
-`doc/source/release.rst` and `doc/source/vx.y.z.txt` contain an ongoing
36
+
changelog for each release. Add entries to these files
37
+
as needed in a separate commit in your PR: document the fix, enhancement,
38
+
or (unavoidable) breaking change.
39
+
- Keep style fixes to a separate commit to make your PR more readable.
42
40
- An informal commit message format is in effect for the project. Please try
43
41
and adhere to it. Check `git log` for examples. Here are some common prefixes
44
42
along with general guidelines for when to use them:
@@ -49,69 +47,25 @@ your contribution or address the issue you're having.
49
47
-**BLD**: Updates to the build process/scripts
50
48
-**PERF**: Performance improvement
51
49
-**CLN**: Code cleanup
52
-
- Commit messages should have:
53
-
- a subject line with `< 80` chars
54
-
- one blank line
55
-
- a commit message body, if there's a need for one
56
-
- If you are changing any code, you should enable Travis-CI on your fork
57
-
to make it easier for the team to see that the PR does indeed pass all the tests.
58
-
-**Backward-compatibility really matters**. Pandas already has a large user base and
59
-
a lot of existing user code.
60
-
- Don't break old code if you can avoid it.
61
-
- If there is a need, explain it in the PR.
62
-
- Changes to method signatures should be made in a way which doesn't break existing
63
-
code. For example, you should beware of changes to ordering and naming of keyword
64
-
arguments.
50
+
- Maintain backward-compatibility. Pandas has lots of users with lots of existing code. Don't break it.
51
+
- If you think breakage is required clearly state why as part of the PR.
52
+
- Be careful when changing method signatures.
65
53
- Add deprecation warnings where needed.
66
-
- Performance matters. You can use the included `test_perf.sh`
67
-
script to make sure your PR does not introduce any new performance regressions
68
-
in the library.
54
+
- Performance matters. Make sure your PR hasn't introduced perf regressions by using `test_perf.sh`.
69
55
- Docstrings follow the [numpydoc](https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt) format.
56
+
- When writing tests, use 2.6 compatible `self.assertFoo` methods. Some polyfills such as `assertRaises`
57
+
can be found in `pandas.util.testing`.
58
+
- Generally, pandas source files should not contain attributions. You can include a "thanks to..."
59
+
in the release changelog. The rest is `git blame`/`git log`.
60
+
- For extra brownie points, you can squash and reorder the commits in your PR using `git rebase -i`.
61
+
Use your own judgment to decide what history needs to be preserved. If git frightens you, that's OK too.
62
+
- Use `raise AssertionError` over `assert` unless you want the assertion stripped by `python -o`.
70
63
-**Don't** merge upstream into a branch you're going to submit as a PR.
71
64
This can create all sorts of problems. Use `git rebase` instead. This ensures
72
65
no merge conflicts occur when your code is merged by the core team.
73
-
- Please reference the GH issue number in your commit message using `GH1234`
74
-
or `#1234`. Either style is fine.
75
-
- Use `raise AssertionError` rather then plain `assert` in library code (`assert` is fine
76
-
for test code). `python -o` strips assertions. Better safe than sorry.
77
-
- When writing tests, don't use "new" assertion methods added to the `unittest` module
78
-
in 2.7 since pandas currently supports 2.6. The most common pitfall is:
79
-
80
-
with self.assertRaises(ValueError):
81
-
foo
82
-
83
-
84
-
which fails with Python 2.6. You need to use `assertRaises` from
85
-
`pandas.util.testing` instead (or use `self.assertRaises(TheException,func,args)`).
86
-
87
-
-`doc/source/release.rst` and `doc/source/vx.y.z.txt` contain an ongoing
88
-
changelog for each release. Add entries to these files
89
-
as needed in a separate commit in your PR: document the fix, enhancement,
90
-
or (unavoidable) breaking change.
91
-
- For extra brownie points, use `git rebase -i` to squash and reorder
92
-
commits in your PR so that the history makes the most sense. Use your own
93
-
judgment to decide what history needs to be preserved.
94
-
- Pandas source code should not -- with some exceptions, such as 3rd party licensed code --
95
-
generally speaking, include an "Authors" list or attribution to individuals in source code.
96
-
`RELEASE.rst` details changes and enhancements to the code over time.
97
-
A "thanks goes to @JohnSmith." as part of the appropriate entry is a suitable way to acknowledge
98
-
contributions. The rest is `git blame`/`git log`.
99
-
Feel free to ask the commiter who merges your code to include such an entry
100
-
or include it directly yourself as part of the PR if you'd like to.
101
-
**We're always glad to have new contributors join us from the ever-growing pandas community.**
102
-
You may also be interested in the copyright policy as detailed in the pandas [LICENSE](https://github.com/pydata/pandas/blob/master/LICENSE).
66
+
- The pandas copyright policy is detailed in the pandas [LICENSE](https://github.com/pydata/pandas/blob/master/LICENSE).
103
67
- On the subject of [PEP8](http://www.python.org/dev/peps/pep-0008/): yes.
104
-
- On the subject of massive PEP8 fix PRs touching everything, please consider the following:
105
-
- They create noisy merge conflicts for people working in their own fork.
106
-
- They make `git blame` less effective.
107
-
- Different tools / people achieve PEP8 in different styles. This can create
108
-
"style wars" and churn that produces little real benefit.
109
-
- If your code changes are intermixed with style fixes, they are harder to review
110
-
before merging. Keep style fixes in separate commits.
111
-
- It's fine to clean-up a little around an area you just worked on.
112
-
- Generally it's a BAD idea to PEP8 on documentation.
113
-
114
-
Having said that, if you still feel a PEP8 storm is in order, go for it.
68
+
- On the subject of a massive PEP8-storm touching everything: not too often (once per release works).
115
69
116
70
### Notes on plotting function conventions
117
71
@@ -137,11 +91,7 @@ Here's a few high-level notes:
137
91
138
92
See the Green "Good to merge!" banner? that's it.
139
93
140
-
This is especially important for new contributors, as members of the pandas dev team
141
-
like to know that the test suite passes before considering it for merging.
142
-
Even regular contributors who test religiously on their local box (using tox
143
-
for example) often rely on a PR+travis=green to make double sure everything
144
-
works ok on another system, as occasionally, it doesn't.
94
+
It's important to get travis working as PRs won't generally get merged until travis is green.
0 commit comments