Changes between Version 3 and Version 4 of CodeReview


Ignore:
Timestamp:
Aug 9, 2014, 5:30:13 PM (4 years ago)
Author:
dustin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CodeReview

    v3 v4  
    1 At a minimum, a patch should:
    2  1. pass the entire test suite reliably
    3  1. pass 'make pyflakes'
    4  1. include documentation (in {{{master/docs}}}) for any new or changed functionality
    5  1. be licensed under the GPLv2 (this is assumed for any contribution; see LicensingYourContribution)
    6  1. be compatible with Python-2.5
    7 
    8 = Tests =
    9 In general, all new functionality should have tests.  However, at the moment some parts of Buildbot have very few tests and are difficult to write tests for, so this is not a hard-and-fast rule.
    10 
    11 = Docstrings =
    12 Buildbot has had an inconsistent history with respect to docstrings.  We now follow a policy of documenting something once.  Thus, if a class is intended for use by users (e.g., a new step), it should be documented in the Texinfo documentation ({{{master/docs}}}) and ''not'' in a docstring.  Conversely, if the changed code is part of an internal Buildbot interface, then it should have a docstring.
    13 
    14 = Style =
    15 Try to adhere to TwistedStyle, and see [http://buildbot.net/buildbot/docs/latest/Buildbot-Tests.html Buildbot Tests] for guidelines on writing tests.  Things to avoid:
    16  * overly long {{{try}}} blocks with a blanket {{{except}}}.  These can tend to hide mistakes made when modifying the code.
    17  * hard-coded values that users might want to adjust
    18  * difficult-to-follow path of execution.  Use nested functions for long deferred chains, rather than methods like {{{_myMethod1}}}, {{{_myMethod2}}}, etc.
     1See PatchReview