Contribution Guidelines

Bryn M. Reeves edited this page Jun 30, 2016 · 11 revisions

Submitting Pull requests:

  • Commit messages should be split over multiple lines where necessary and are (with the exception of e.g. long command, log, or other output that should be included verbatim) hard-wrapped at 72 characters.

  • Please write clear commit subjects and messages

    • The subject should make it clear what the patch changes for e.g.:

      [archive] Fix TarArchive permission handling

      is preferred over:

      Fix permission handling

    • Commits that affect a single plugin should be tagged with the plugin name in brackets in the subject line, for e.g.:

      [networking] Add NetworkManager nmcli support

    • Include any issues the code fixes (e.g. Closes: #1) on a separate line
    • If working around python or other external behavior describe this in the full commit message for e.g.:
commit 6501013bb780161e941f5e078a6ed7052f670a51
Author: Bryn M. Reeves <>
Date:   Mon Jun 2 15:27:10 2014 +0100

    Make sure grub password regex handles all cases

    The regex to match passwords in grub.conf needs to handle both
    the --md5 and non-md5 cases and to apply the substitution only
    to the secret part (password or password hash).

    This needs to deal with the fact that python will return 'None'
    for unmatched pattern groups leading to an exception in re.subn()
    if not all referenced groups match for a given string (in contrast
    to e.g. the perl approach of treating these groups as the empty

    Make this explicit by using an empty alternate in the possibly
    unmatched '--md5' group:


    Signed-off-by: Bryn M. Reeves <>
  • Each developer should fork sosreport into their accounts repository.
    • Not required, but advisable to use feature/patch branches when working with new code.
  • All pull requests should be against master branch
  • We avoid merge commits in master so branches may need to be rebased over the master-du-jour prior to merging
  • All unit tests must pass before the pull request is accepted.
    • Testing for sos is automated - a Travis build is run for each pull request.
    • To save time developers can enable local git test hooks
  • All commits must be accompanied by a Signed-off-by: Firstname Lastname <>
    • <email at example dot com> and other obfuscations are fine too.
    • Use git commit -s to automatically add a Signed-off-by with your configured git user details.
  • Make sure you are following pep8 style guidelines

Optional but very helpful

  • An sosreport archive generated using the changed code
  • Any functional tests we should be aware of in order to verify the pull requests.
  • Where possible a test case for the in-tree nosetest suite
    • See the existing cases in tests/ for examples