Differences between revisions 2 and 4 (spanning 2 versions)
⇤ ← Revision 2 as of 2012-01-06 01:21:25 →
Size: 1183
Editor: kini
Comment:
← Revision 4 as of 2012-01-06 08:38:15 → ⇥
Size: 2381
Editor: jdemeyer
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
This is a checklist that can be consulted when reviewing a patch. 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.
Line 5: Line 9:
 * The patch should apply cleanly on top of the latest [[http://sagemath.org/download-latest.html|development release]].  * The patch should apply cleanly on top of the latest [[http://sagemath.org/download-latest.html|development release]].  "cleanly" in particular means without "fuzz".
Line 7: Line 11:
 * The patch should be generated by Mercurial and have a sensible commit message, including the trac ticket number.  * 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.
Line 9: Line 13:
 * Run an interactive sage session, and manually exercise the affected code.  * 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.
Line 13: Line 17:
 * Run `sage -docbuild reference html` to rebuild the reference docs. View any affected pages.  * Documentation should be formatted according to the [[http://sagemath.org/doc/developer/conventions.html#documentation-strings|developer's guide]]
 * Run `sage --docbuild reference html` to rebuild the reference docs. View any affected pages.
Line 21: Line 26:
 * 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)
Line 24: Line 31:
 * '''All''' new functions must have INPUT, OUTPUT, EXAMPLES, and TESTS sections.  * ''All'' new functions should have INPUT, OUTPUT, EXAMPLES, and TESTS sections where applicable.
 * New files should have a heading as shown in the [[http://sagemath.org/doc/developer/conventions.html#headings-of-sage-library-code-files|developer's guide]]

=== Trac ===

 * Add the real name of the Author(s) and Reviewer(s) of the patch on Trac.
 * Add youself to [[http://trac.sagemath.org/sage_trac/#AccountNamesMappedtoRealNames|Account Names Mapped to Real Names]]

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.

  • 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.

  • 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.
  • 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.

  • New files should have a heading as shown in the developer's guide

Trac

ReviewChecklist (last edited 2023-02-23 20:15:26 by mkoeppe)