Patch submission guidelines

On 1/23/08, Eric B. [email protected] wrote:

After we’ve seen a series of good patches from you that apply cleanly,
and follow our conventions, we can talk about getting you write
access to the repo.

None of the below are mandatory, but are some conventions to follow to
help us more easily evaluate and apply a patch. These are not just
for documentation patches, but for functionality as well:

  • Patches are submitted in the form of a SVN created diff, not
    individual files.

  • Diffs are made from the GNU Radio tree root, and are based on an SVN
    check out of the GNU Radio trunk.

  • The diff contains the minimal but related incremental changes, for
    all the files needing modification to implement the change. In other
    words, the diff should take a working GNU Radio source tree and modify
    it to become a working GNU Radio source tree with the feature
    implemented.

  • After applying the diff, the tests ‘make check’ and ‘make distcheck’
    must both pass.

  • When relevant, QA code exists to automate unit testing of the new
    functionality.

  • There should be no additional compiler warnings to what already
    occurs.

  • No gratuitous whitespace changes.

It does take time and practice to follow the above, so again, the
above aren’t rules, but more of a “scoring system” that will improve
the chance of your contribution being accepted into the project.

Incidentally, these are the same criteria that we review before we
merge code from our developer branches into the trunk.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs