warewulf/MAINTAINING.md

# 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.”

- Any new major release is preceeded by one or more release candidates.

### Minor releases

- A minor release is denoted by a tag named `v4.MINOR.0`.

- Minor releases are defined by a previously-planned milestone named
  for the projected release.

- 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.

- A minor release may be preceeded by one or more release candidates.

### 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.

- Patch releases are not typically preceeded by release candidates.

### Release candidates

- A 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).

- Once a release candidate has been published, the related final 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.

## Golang version

- Warewulf is built with the most recent version of Go that is available
  as a system package across the Linux distributions for which Warewulf
  [publishes official packages](https://github.com/warewulf/warewulf/blob/main/.github/workflows/release.yml),
  in consultation with the OpenHPC project and its Go version requirements.

- The minimum Go version declared in `go.mod` is updated at the start
  of each minor release cycle to reflect the Go version available
  across all supported distributions.

### Notes

- On EL8, Go is installed using the `go-toolset` module from the
  appstream repository.
- OpenHPC uses https://eur.openeuler.openatom.cn/coprs/openhpc/OpenHPC/packages/ to build for openEuler.