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