1NOTES FOR GITHUB DEVELOPERS
2---------------------------
3
4The official issue tracker for Slurm is at
5  https://bugs.schedmd.com/
6
7We welcome code contributions and patches, but **we do not accept Pull Requests
8through GitHub at this time.** Please submit patches as attachments to new
9bugs under the "C - Contributions" severity level.
10
11TARGET RELEASES
12---------------
13Changes involving adding new functionality, functional changes to the command
14line tools (either in adding new options, or changing the output formats), any
15RPC protocol changes or state file format modifications, and similar work is
16only considered for inclusion on the master branch (which will become the next
17stable Slurm release).
18
19Bug fixes themselves are considered for inclusion on the most recent stable
20release, although may be deferred to the next major release at the reviewers'
21discretion.
22
23All contributed patches are subject to review by SchedMD.
24
25CODING GUIDELINES
26-----------------
27Slurm loosely follows the Linux Kernel style guidelines
28(https://www.kernel.org/doc/html/latest/process/coding-style.html).
29If in doubt, please follow their example.
30
31A brief overview, with some notable exceptions:
32- Tabs not spaces, tabs are 8-spaces wide.
33- Lines should be less than 80-characters wide.
34- Except that error message and other log messages should not be broken up
35  mid-sentence. They should be split on a format sequence, comma, or period
36  instead. (This is to make it easier to grep for that string in the source
37  code at a later point.)
38- Use K&R style for braces.
39- Slurm does use typedef's for certain types, ignore Chapter 5 of the kernel
40  guidelines.
41- Comments can be in either C-style `/* comment */` or C++ style  `// comment`
42  formats. Follow the rest of Chapter 8's recommendations for multi-line
43  comments though.
44
45BUILD SYSTEM CHANGES
46--------------------
47Please submit changes to `Makefile.am`, but not to `Makefile.in`. We will
48regenerate those files to minimize the differences in the commit. We want to
49avoid noise generated by differences in libtool installations.
50
51Changes to `configure.ac` or `auxdir/*` will take additional time to review -
52Slurm is built on a wide variety of distributions and architectures, and even
53minor differences can cause unintended consequences.
54
55PATCH SUBMISSION
56----------------
57An entry in `NEWS` should describe the change or new functionality.
58
59Please break patches up into logically separate chunks, while ensuring that
60each patch can still be compiled. (Anticipate that a developer using `git
61bisect` may pick any intermediate commit at some point.)
62
63If you decided to reformat a file, please submit non-functional changes
64(spelling corrections, formatting discrepancies) in a separate patch. This
65makes reviewing substantially easier, and allows us to focus our attention on
66the functional differences.
67
68If you make an automated change (changing a function name, fixing a pervasive
69spelling mistake), please send the command/regex used to generate the changes
70along with the patch, or note it in the commit message.
71
72While not required, we encourage use of `git format-patch` to generate the
73patch. This ensures the relevant author line and commit message stay attached.
74Plain `diff`'d output is also okay. In either case, please attach them to the
75bug for us to review. Spelling corrections or documentation improvements can be
76suggested without attaching the patch as long as you describe their location.
77
78LEGAL
79-----
80
81We ask that a contributor licensing agreement be signed for all substantial
82contributions. Please see https://slurm.schedmd.com/contributor.html for
83details.
84