forked from warewulf/warewulf
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Split contributing an maintenance policies
Signed-off-by: Jonathon Anderson <[email protected]>
- Loading branch information
1 parent
03fe1a4
commit 26aa022
Showing
2 changed files
with
111 additions
and
104 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,107 @@ | ||
| # Maintaining | ||
|
|
||
| ## 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. | ||
|
|
||
| ## Merging | ||
|
|
||
| - 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. | ||
|
|
||
| ## 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. |