134 lines
4.9 KiB
Markdown
134 lines
4.9 KiB
Markdown
# Maintaining
|
|
|
|
## Technical Steering Committee
|
|
|
|
(in alphabetical order by surname)
|
|
|
|
- [Anderson, Jonathon](janderson@ciq.com) (CIQ)
|
|
- [Goll, Christian](cgoll@suse.de) (SUSE)
|
|
- [Kurtzer, Greg](gmk@ciq.com) (CIQ)
|
|
- [Middelkoop, Timothy](tmiddelkoop@internet2.edu) (Internet2)
|
|
- [Siadal, Jeremy](jeremy.c.siadal@intel.com) (Intel)
|
|
|
|
TSC chair: Jonathon Anderson (November 2023)
|
|
|
|
The Warewulf technical steering committee (TSC) leads roadmapping,
|
|
development, and release publication for the Warewulf project. It
|
|
meets twice monthly at a Warewulf steering committee meeting convened
|
|
by the TSC chair.
|
|
|
|
New TSC members may be nominated by an existing member of the TSC, and
|
|
may be admitted by consensus vote by the existing TSC members.
|
|
|
|
The TSC chair is selected by the TSC once per year in November.
|
|
|
|
TSC members should advise the TSC when they are no longer able to
|
|
continue in their role. The member is then removed from the committee
|
|
by vote of the remaining TSC members.
|
|
|
|
## 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.
|