    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.