| NOTES FOR GITHUB DEVELOPERS |
| --------------------------- |
| |
| The official issue tracker for Slurm is at |
| https://bugs.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 |
| bugs 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 |
| ---------------- |
| An entry in `NEWS` 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. |
| |
| While not required, we encourage use of `git format-patch` to generate the |
| patch. This ensures the relevant author line and commit message stay attached. |
| Plain `diff`'d output is also okay. In either case, please attach them to the |
| bug for us to review. Spelling corrections or documentation improvements can be |
| suggested without attaching the patch as long as you describe their location. |
| |
| LEGAL |
| ----- |
| |
| We ask that a contributor licensing agreement be signed for all substantial |
| contributions. Please see https://slurm.schedmd.com/contributor.html for |
| details. |
