diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9dbe67bd..c750642a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -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). diff --git a/MAINTAINING.md b/MAINTAINING.md new file mode 100644 index 00000000..ab211dcf --- /dev/null +++ b/MAINTAINING.md @@ -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.