NOTES FOR DEVELOPERS

The official issue tracker for Slurm is at https://support.schedmd.com/

We welcome code contributions and patches, but we do not accept Pull Requests through GitHub at this time. Please submit patches as attachments to new tickets under the “C - Contributions” severity level.

TARGET RELEASES

Changes involving adding new functionality, functional changes to the command line tools (either in adding new options, or changing the output formats), any RPC protocol changes or state file format modifications, and similar work is only considered for inclusion on the master branch (which will become the next stable Slurm release).

Bug fixes themselves are considered for inclusion on the most recent stable release, although may be deferred to the next major release at the reviewers' discretion.

All contributed patches are subject to review by SchedMD.

CODING GUIDELINES

Slurm loosely follows the Linux Kernel style guidelines (https://www.kernel.org/doc/html/latest/process/coding-style.html). If in doubt, please follow their example.

A brief overview, with some notable exceptions:

  • Tabs not spaces, tabs are 8-spaces wide.
  • Lines should be less than 80-characters wide.
  • Except that error message and other log messages should not be broken up mid-sentence. They should be split on a format sequence, comma, or period instead. (This is to make it easier to grep for that string in the source code at a later point.)
  • Use K&R style for braces.
  • Slurm does use typedef's for certain types, ignore Chapter 5 of the kernel guidelines.
  • Comments can be in either C-style /* comment */ or C++ style // comment formats. Follow the rest of Chapter 8's recommendations for multi-line comments though.

BUILD SYSTEM CHANGES

Please submit changes to Makefile.am, but not to Makefile.in. We will regenerate those files to minimize the differences in the commit. We want to avoid noise generated by differences in libtool installations.

Changes to configure.ac or auxdir/* will take additional time to review - Slurm is built on a wide variety of distributions and architectures, and even minor differences can cause unintended consequences.

PATCH SUBMISSION

A "Changelog: " trailer in the commit message should describe the change or new functionality.

Please break patches up into logically separate chunks, while ensuring that each patch can still be compiled. (Anticipate that a developer using git bisect may pick any intermediate commit at some point.)

If you decided to reformat a file, please submit non-functional changes (spelling corrections, formatting discrepancies) in a separate patch. This makes reviewing substantially easier, and allows us to focus our attention on the functional differences.

If you make an automated change (changing a function name, fixing a pervasive spelling mistake), please send the command/regex used to generate the changes along with the patch, or note it in the commit message.

We strongly encourage the use of git format-patch to generate the patch. This ensures the relevant author line and commit message stay attached. Spelling corrections or documentation improvements can be suggested without attaching the patch as long as you describe their location.