Community

• 1: Governance
• 2: Contributing
• 3: Roadmap
• 4: Subprojects

1 - Governance

Code of Conduct

Lima follows the CNCF Code of Conduct.

Maintainership

Lima is governed by Maintainers who are elected from active contributors.

As a Cloud Native Computing Foundation project, Lima will keep its vendor-neutrality.

Roles

Maintainers consist of two roles:

• Committer (Full maintainership): Committers have full write accesses to repos under https://github.com/lima-vm. Committers’ commits should still be made via GitHub pull requests (except for urgent security fixes), and should not be pushed directly. Committers must enable 2FA for their GitHub accounts. Committers are also recognized as Maintainers in https://github.com/cncf/foundation/blob/main/project-maintainers.csv.

• Reviewer (Limited maintainership): Reviewers may moderate GitHub issues and pull requests (such as adding labels and cleaning up spams), but they do not have any access to merge pull requests nor push commits. A Reviewer is considered as a candidate to become a Committer. Reviewers are not recognized as Maintainers in https://github.com/cncf/foundation/blob/main/project-maintainers.csv.

See also the Contributing page.

Current maintainers

Addition and promotion of Maintainers

An active contributor to the project can be invited as a Reviewer, and can be eventually promoted to a Committer after 2 months at least.

A contributor who have made significant contributions in quality and in quantity can be also directly invited as a Committer.

A proposal to add or promote a Maintainer must be approved by 2/3 of the Committers who vote within 7 days. Voting needs 2 approvals at least. The proposer can vote too.

A proposal should happen as a GitHub pull request to the Maintainer list above. It is highly suggested to reach out to the Committers before submitting a pull request to check the will of the Committers.

Removal and demotion of Maintainers

A Maintainer who do not show significant activities for 6 months, or, who have been violating the Code of Conduct, may be demoted or removed from the project.

A proposal to demote or remove a Maintainer must be approved by 2/3 of the Committers (excluding the person in question) who vote within 14 days. Voting needs 2 approvals at least. The proposer can vote too.

A proposal may happen as a GitHub pull request, or, as a private discussion in the case of removal of a harmful Maintainer. It is highly suggested to reach out to the Committers before submitting a pull request to check the will of the Committers.

Other decisions

Any decision that is not documented here can be made by the Committers. When a dispute happens across the Committers, it will be resolved through a majority vote within the Committers. A tie should be considered as a failed vote.

Release process

Eligibility to be a release manager:

• MUST be an active Committer
• MUST have the GPG fingerprint listed in the maintainer list above
• MUST upload the GPG public key to https://github.com/USERNAME.gpg
• MUST protect the GPG key with a passphrase or a hardware token.

Release steps:

• Open an issue to propose making a new release, e.g. https://github.com/lima-vm/lima/issues/2296. The proposal should be public, with an exception for vulnerability fixes. If this is the first time for you to take a role of release management, you SHOULD make a beta (or alpha, RC) release as an exercise before releasing GA.
• Make sure that all the merged PRs are associated with the correct Milestone.
• Run git tag --sign vX.Y.Z-beta.W .
• Run git push UPSTREAM vX.Y.Z-beta.W .
• Wait for the Release action on GitHub Actions to complete. A draft release will appear in https://github.com/lima-vm/lima/releases .
• Download SHA256SUMS from the draft release, and confirm that it corresponds to the hashes printed in the build logs on the Release action.
• Sign SHA256SUMS with gpg --detach-sign -a SHA256SUMS to produce SHA256SUMS.asc, and upload it to the draft release.
• Add release notes in the draft release, to explain the changes and show appreciation to the contributors. Make sure to fulfill the Release manager: [ADD YOUR NAME HERE] (@[ADD YOUR GITHUB ID HERE]) line with your name. e.g., Release manager: Akihiro Suda (@AkihiroSuda) .
• Click the Set as a pre-release checkbox if this release is a beta (or alpha, RC).
• Click the Publish release button.
• Close the Milestone.

2 - Contributing

Developer Certificate of Origin

Every commit must be signed off with the Signed-off-by: REAL NAME <email@example.com> line.

Use the git commit -s command to add the Signed-off-by line.

See also https://github.com/cncf/foundation/blob/main/dco-guidelines.md.

Licensing

Lima is licensed under the terms of Apache License, Version 2.0.

See also https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md for third-party dependencies.

Sending pull requests

Pull requests can be submitted to https://github.com/lima-vm/lima/pulls.

It is highly suggested to add tests for every non-trivial pull requests. A test can be implemented as a unit test rather than an integration test when it is possible, to avoid slowing the integration test CI.

Merging pull requests

Committers can merge pull requests. Reviewers can approve, but cannot merge, pull requests.

A Committer shouldn’t merge their own pull requests without approval by at least one other Maintainer (Committer or Reviewer).

This rule does not apply to trivial pull requests such as fixing typos, CI failures, and updating image references in templates (e.g., https://github.com/lima-vm/lima/pull/2318).

3 - Roadmap

Instead of using a static text file, Lima uses the roadmap label on GitHub issues to designate features or bug fixes that we plan to implement.

Issues are tagged with the roadmap label when at least one maintainer or contributor has declared intent to work on or help with the implementation.

There are no commitments or timelines attached to the label, and the label may be removed again from an abandoned issue at any time.

Non-roadmap issues are kept open (as long as they fit the scope of the project) in case a volunteer one day appears and offers to work on them.

To find the items currently planned for Lima you can filter on open issues with the roadmap label.

4 - Subprojects

Some portions of Lima are useful for other projects too and split out to separate repos:

• https://github.com/lima-vm/socket_vmnet: vmnet.framework support for unmodified rootless QEMU
• https://github.com/lima-vm/go-qcow2reader: qcow2 reader for Go
• https://github.com/lima-vm/sshocker: ssh + reverse sshfs + port forwarder, in Docker-like CLI (predecessor of Lima)
• https://github.com/lima-vm/alpine-lima: Create an alpine based image for lima

See also https://github.com/lima-vm for other subprojects.

The maintainership of the subprojects corresponds to the maintainership of Lima itself.