NOTES FOR DEVELOPERS

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

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 uses clang-format and pre-commit to automatically manage the coding style. The provided .clang-format file and .pre-commit-config.yaml files should be used for new commits. Please avoid reformatting lines that are otherwise unchanged by your patch.

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.

DEVELOPER CERTIFICATE OF ORIGIN

We require that all contributors “sign-off” on all submitted commits. This certifies that the contribution is your original work, or you have rights to submit it under the same license, or a compatible license.

Any contribution which contains commits that are not Signed-Off will not be accepted.

To sign off on a commit you simply use the --signoff (or -s) option when committing your changes:

$ git commit -s -m "Add cool feature"

This will append the following to your commit message:

Signed-off-by: Your Name <your@email.com>

By signing off, you certify the Developer Certificate of Origin 1.1:

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.