kelvin/warewulf
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Split contributing an maintenance policies

Browse Source 
Signed-off-by: Jonathon Anderson <janderson@ciq.com>
This commit is contained in:
Jonathon Anderson
2023-10-13 23:19:48 -06:00
parent 03fe1a4434
commit 26aa022c59
2 changed files with 111 additions and 104 deletions
Download Patch File Download Diff File Expand all files Collapse all files

108
CONTRIBUTING.md
View File

@@ -99,108 +99,8 @@ thereof, in binary and source code form.
- No other branches are maintained in the primary Warewulf repository.
## Merging
## Maintaining
- All new contributions to the project should first be merged through
a PR to the `main` branch.
- Patches to a minor branch should be copied ("cherry-picked") from a
previously-merged PR.
- Each PR must, prior to merge, be reviewed and approved by a
committer other than the author of the PR.
- Before approving of a PR, an approver must confirm that
- all lint checks and tests pass with the given PR;
- new tests to cover the change have been added as appropriate;
- all commits in the PR have an appropriate DCO “Signed-Off-By”;
- documentation, including (but not necessarily limited to) the
CHANGELOG and user guide, have been updated appropriately.
- Any committer may, at his discretion, merge a PR that has the
requisite approvals and for which all tests are passing. This
includes, but is not limited to, a reviewer of the PR or the author
of the PR.
- Committers should consider the current roadmap when choosing to
approve or merge a given PR. For example, proper and successful
bugfixes are likely always appropriate to merge. However, new
features may not be appropriate to merge if they are not included in
the next milestone. New features which incompatibly alter existing
interfaces or behavior should not be approved or merged unless
included in the current milestone.
- Committers which approve or merge PRs which are disruptive to the
current milestone may have their committer access revoked by the
TSC.
## Roadmapping
- The project roadmap is formally defined by GitHub milestones
associated with the primary Warewulf repository.
- The roadmap, and its milestones, are drafted and managed by the TSC
chair to reflect and codify the priorities of the TSC and the
community. Definition of the roadmap includes, but is not limited to
- the name, description, and due date for each milestone;
- the issues and PRs associated with a given milestone.
- Only the TSC chair may assign issues to or remove issues from
milestones. The TSC chair has proactive discretion to assign or move
issues to reflect and codify the priorities of the TSC and the
community, but may not act in opposition to the direction of the
TSC.
- Requests for changes to the roadmap that are made in the Warewulf
community meeting are recorded in the Warewulf community journal.
## Releases
- Warewulf releases follow a `MAJOR.MINOR.PATCH` format.
- Releases are generated by an automated process encoded as a GitHub
actions workflow.
- All releases must pass the full Warewulf test suite.
- Releases are published by a member of the TSC at the direction of
the TSC.
- Each release is accompanied by an updated changelog.
### Major releases
- All releases occur within major version “4.”
### Minor releases
- A minor release is denoted by a tag named `v4.MINOR.0`.
- A minor release candidate is denoted by a tag named
`v4.MINOR.0rcNUMBER`, where `NUMBER` begins at “1” and increments
for each candidate for the given minor release.
- Minor releases are defined by a previously-planned milestone named
for the projected release.
- A minor release candidate may be published by the TSC when all
functional issues and pull requests in the associated milestone are
closed. (e.g., documentation issues and pull requests may remain.)
This may also be accomplished by the TSC re-scoping the associated
milestone (e.g., by moving issues or pull requests to a different
milestone).
- A minor release may be published by the TSC two weeks after a
release candidate if no major defects have been found in the release
candidate and there are no open issues or pull requests.
### Patch releases
- A patch release is denoted by a tax named `v4.MINOR.PATCH` where
`PATCH` is greater than `0`, and tags a commit on a minor branch.
- The TSC may identify changes in the “main” branch to be ported to a
minor branch.
- A patch release may be published by the TSC whenever one or more
changes have been ported to a minor branch.
Additional policies regarding the maintenance of the Warewulf source
code, including roadmapping, merging, and release policies, is
documented at [MAINTAINING.md](MAINTAINING.md).