|
Size: 2602
Comment:
|
Size: 2857
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 21: | Line 21: |
| * Run `sage --docbuild reference html` to rebuild the reference docs. View any affected pages. | * Run `sage --docbuild reference html` to rebuild the reference docs. View any affected pages. You can use the extra option `--warn-links` as in `sage --docbuild --warn-links reference html` to see if all links are properly resolved. |
| Line 28: | Line 28: |
| * If the patch fixes a defect, there should be a doctest checking that the defect is fixed, and the comment should mention the trac ticket number. | * If the patch fixes a defect, there should be a doctest checking that the defect is fixed, and the comment should mention the trac ticket number. You can use the special sphinx markup {{{:trac:`12314`}}} for that. |
| Line 34: | Line 34: |
| * ''All'' new functions should have INPUT, OUTPUT, EXAMPLES, and TESTS sections where applicable. | * ''All'' new functions should have INPUT, OUTPUT, EXAMPLES, and TESTS sections where applicable. `.. SEEALSO::` section is highly recommended. |
Review Checklist
This is a checklist that can be consulted when authoring or reviewing a patch.
Read the patch
- Most importantly, have a look at the patch and see what it does.
General
The patch should apply cleanly on top of the latest development release. "cleanly" in particular means without "fuzz".
- There should be no trailing whitespace on any line touched by the patch.
The patch should be generated by Mercurial (preferably using hg export tip) and have a sensible commit message. A multi-line commit message is allowed and in fact encouraged. The first line (which will be shown by hg log) should make sense by itself.
make ptestlong should pass with the patch applied.
If the patch could impact any optional packages or tests, install those optional packages and run the optional tests using sage -t -only_optional=package. See #6329 for what *not* to do.
- Run an interactive sage session, and manually exercise the affected code. Try in particular some corner cases or stuff not mentioned in the EXAMPLES section.
Documentation
Documentation should be formatted according to the developer's guide
Run sage --docbuild reference html to rebuild the reference docs. View any affected pages. You can use the extra option --warn-links as in sage --docbuild --warn-links reference html to see if all links are properly resolved.
- View affected documentation from within a sage session.
- All variables in documentation should be enclosed in backticks.
Doctests
All new code should be doctested. Use sage --coverageall to make sure the doctest coverage has not gone down.
If the patch fixes a defect, there should be a doctest checking that the defect is fixed, and the comment should mention the trac ticket number. You can use the special sphinx markup :trac:`12314` for that.
- Add a TESTS section to test corner cases or (for a bugfix ticket) cases fixed by the patch.
- Also doctest exceptions. For example, when writing a function for division, test that dividing by zero yields a reasonable exception (as opposed to a crash of Sage)
New Functions
All new functions should have INPUT, OUTPUT, EXAMPLES, and TESTS sections where applicable. .. SEEALSO:: section is highly recommended.
New files should have a heading as shown in the developer's guide
Trac
- Add the real name of the Author(s) and Reviewer(s) of the patch on Trac.
Add youself to Account Names Mapped to Real Names