eaaa1bd7e9
Jonathon was elected TSC chair at the in-person SC23 meeting 13 November 2023, along with the ratification of the contributing and maintenance policies. Signed-off-by: Jonathon Anderson <janderson@ciq.com>
109 lines
4.0 KiB
Markdown
109 lines
4.0 KiB
Markdown
# Contributing
|
|
|
|
## Contributor's Agreement
|
|
|
|
You are under no obligation whatsoever to provide any bug fixes,
|
|
patches, or upgrades to the features, functionality or performance of
|
|
the source code ("Enhancements") to anyone; however, if you choose to
|
|
make your Enhancements available either publicly, or directly to the
|
|
project, without imposing a separate written license agreement for
|
|
such Enhancements, then you hereby grant the following license: a
|
|
non-exclusive, royalty-free perpetual license to install, use, modify,
|
|
prepare derivative works, incorporate into other computer software,
|
|
distribute, and sublicense such enhancements or derivative works
|
|
thereof, in binary and source code form.
|
|
|
|
## Technical Steering Committee
|
|
|
|
(in alphabetical order by surname)
|
|
|
|
- [Anderson, Jonathon](janderson@ciq.com) (CIQ)
|
|
- [Goll, Christian](cgoll@suse.de) (SUSE)
|
|
- [Hanks, John](griznog@gmail.com) (Chan Zuckerburg Biohub)
|
|
- [Kurtzer, Greg](gmk@ciq.com) (CIQ)
|
|
- [Siadal, Jeremy](jeremy.c.siadal@intel.com) (Intel)
|
|
|
|
TSC chair: Jonathon Anderson
|
|
|
|
## Pull requests
|
|
|
|
- All commits must be "Signed-off" (i.e., by using `git commit -s`),
|
|
acknowledging that you agree to the [Developer Certificate of
|
|
Origin](DCO.txt).
|
|
|
|
- All PRs should summarize the purpose of the PR in the attached
|
|
GitHub conversation.
|
|
|
|
- Larger fixes or enhancemens should be discussed with the TSC or
|
|
developers, e.g., on Slack or over Email.
|
|
|
|
- PRs should be sent to the `main` branch by default. A committer or
|
|
the TSC may request that certain bug fixes also be submitted to a
|
|
minor release branch.
|
|
|
|
- Follow existing code style precedent. For Go, you should mostly
|
|
conform to the style and form enforced by the "go fmt" and "golint"
|
|
tools for proper formatting.
|
|
|
|
- For any new functionality, please write appropriate go tests. These
|
|
run as part of the continuous integration system.
|
|
|
|
- Make sure that the project's default copyright and header have been
|
|
included in any new source files.
|
|
|
|
- Make sure your code passes linting, by running `make lint` before
|
|
submitting the PR.
|
|
|
|
- Make sure you have locally tested using `make test` and that all
|
|
tests succeed before submitting the PR.
|
|
|
|
- PRs which introduce a new Go dependency to the project should
|
|
explain why the dependency is required. Any new dependency should be
|
|
added to `LICENSE_DEPENDENCIES.md` by running
|
|
`scripts/update-license-dependencies.sh`.
|
|
|
|
## Documentation
|
|
|
|
- The [README](README.md) is a place to document critical information
|
|
for new users of Warewulf. It should typically not change, but in
|
|
the case where a change is necessary a PR may update it.
|
|
|
|
- The [CHANGELOG](CHANGELOG.md) documents **functional** differences
|
|
between versions of Warewulf, and should **not** read like a commit
|
|
log.
|
|
|
|
Once a release is tagged (*e.g. v4.0.0*), a new top level section
|
|
is made titled **Changes Since vX.Y.Z** (*e.g. Changes Since
|
|
v4.0.0*) where new changes are documented, leaving the previous
|
|
section immutable.
|
|
|
|
The CHANGELOG must be updated for any of the following changes:
|
|
- Renamed commands or subcommands
|
|
- Deprecated / removed commands or subcommands
|
|
- Changed defaults / behaviors
|
|
- Backwards-incompatible changes
|
|
- New features / functionalities
|
|
|
|
- The [user guide](https://warewulf.org/docs/) should document
|
|
anything pertinent to the use of Warewulf. Changes to Warewulf
|
|
functionality should simultaneously include pertinent updates to the
|
|
user guide, which is maintained alongside the code under
|
|
`userdocs/`.
|
|
|
|
## Branches
|
|
|
|
- Development occurs primarily on the `main` branch. This is the
|
|
branch that most PRs should be submitted against unless otherwise
|
|
directed.
|
|
|
|
- A minor release is accompanied by a minor branch named `v4.MINOR.x`
|
|
from which patch releases may be generated.
|
|
|
|
- No other branches are maintained in the primary Warewulf repository.
|
|
|
|
## Maintaining
|
|
|
|
Additional policies regarding the maintenance of the Warewulf source
|
|
code, including roadmapping, merging, and release policies, is
|
|
documented at [MAINTAINING.md](MAINTAINING.md).
|