Creating a Samba patch series

From SambaWiki
Revision as of 20:52, 18 June 2020 by Abartlet (talk | contribs) (include info on writing tests)


When contributing to Samba, there are quality expectations that need to be met in order for your patches to be accepted. Please review these guidelines before writing your first commits, otherwise you may need to rebase your patches.

This page is not meant to be a technical overview about using git, there are already plenty of resources for learning to use git. It's expected when you reach this page that you already know these concepts.

What a commit should include

Each git commit should be succinct and only do one thing. Each new feature or bug fix should include a second commit containing a test to validate the change.

A good commit message

Good commit messages are very important. Commits should always be separated in meaningful pieces. Please make sure that your commit messages include at least the following information:

  • A short summary of the fix/feature including the Samba version and component followed by a blank line.
  • A more verbose description.
  • A bug number if available (required for backports to a released branch, so please file a bug first)
  • The description for the release notes starting with "RN: ". Please make sure that administrators understand the issue.
  • Your Signed-off-by tag per the Samba copyright policy


s3:smbd: Add new funky shiny and groovy feature

The funky shiny and groovy feature has been added to
be able to do whatever you like. A typical usecase is the

RN: Fix problem xyz.

Signed-off-by: Author <>


The problem with merge requests is that the Changes view shows a complete product, without intermediate stages. In Samba, we also care about the history when getting to the final product. Small succinct commits make it possible to run git bisect on the history, allowing us to find commits that introduce bugs.

This means that each and every commit must compile on its own.

Each commit in the branch should also be expected to pass a full CI. There is not automatic verification of this, but running a build and the relevant tests locally after each commit is advised on larger merge requests. Use git rebase to do this.

Sometimes developers will argue that reviewers should take the end result as a whole, and evaluate a patch series on it's functionality. We recognize the effort put into preparing patches for Samba, but requests cannot be accepted that are not bisectable.

Write a story (for review)

A merge request is a story, told to the reviewer. It is important that both the MR description and the patches tell the story, as eventually the MR description will be lost but the git commits will remain in the history.

Each commit should tell one step at a time what is being changed, and why. Include some further details of the over-arching design or bug being fixed in a significant commit.

The idea is to bring the reviewer to a shared understanding that each commit is safe, sensible and reasonable alone (even if only fully useful in combination with the later work).

Polished pearls

The end result of a MR is like a string of pearls. Each pearl (commit) individually polished, then assembled as a string. The quality of the end result is almost entirely due to the quality of each element.


Tests should be included in your merge request in their own commit.

How to write tests

Most changes to Samba should have a test to demonstrate the bug being fixed, or test the feature being added. Most tests are run using 'make test' from a Samba source tree.

See writing and running Samba tests but in particular:

  • Writing Torture Tests: smbtorture in the source4/torture directory and provides direct C protocol tests.
  • Writing Python Tests: If the protocol under test is DCERPC, then PIDL will have already auto-generated Python bindings. Likewise LDAP is easily accessed via LDB.
  • Writing cmocka Tests: Idea for unit tests of C functions.
  • LDB: Tests for LDB are in lib/ldb/tests and are run from make test within lib/ldb
  • CTDB: Tests for CTDB are written as shell scripts under ctdb/tests and are run from make test within ctdb

Effective Review

It is the submitter's responsibility to make the most of code review. The reviewer will likely only point out a single instance of any given problem. The submitter is expected to find every instance of this mistake and fix it throughout the code.


What not to do

Here is an actual example from an open source project (identifying information has been removed), of a poorly created merge request:

Github mr 1.png

Github mr 2.png

This request contains 47 commits, the merge request title does not explain what the code change is doing, and the final result is a single line code change!

Assuming the cumulative code change listed here is what was intended (which isn't at all obvious from the merge request title), these 47 commits should have been rebased into a single commit, and likely a test should have been written to test the change.

A good example

Here is an example of a Samba merge request which was created correctly:



This request only has 2 commits, the first commit being the bug fix, and the second commit containing tests for the issue. The merge request title is very specific, mentioning the component being patched, the function name being patched, and explaining very briefly what was fixed. The patch contents only modify the single thing being fixed (excluding the tests).