RFC: standalone OpenVMM source releases - #4150
Conversation
Document the release flow, alternatives, open identity decisions, and phased implementation plan for maintainer consensus. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4fe65aa5-d620-4856-a525-e32bf98c16b1
Limit the initial gate to extracting and building the exact release archive, deferring policy-specific assertions until maintainers agree they are required. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4fe65aa5-d620-4856-a525-e32bf98c16b1
Record the preferred archive, package, CLI, and publication directions while keeping development and exact-tag identities open for maintainer feedback. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4fe65aa5-d620-4856-a525-e32bf98c16b1
Remove tag- and workflow-derived product versions from the release proposal alternatives. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4fe65aa5-d620-4856-a525-e32bf98c16b1
There was a problem hiding this comment.
Pull request overview
Adds an RFC/proposal page to the Developer Guide describing a potential model for producing “standalone” OpenVMM source releases suitable for Linux distribution builds, with an emphasis on separating policy decisions from implementation details.
Changes:
- Introduces a new proposal document outlining goals, a candidate release flow, and an initial distribution-build gate.
- Enumerates explicit “decisions requiring consensus” to guide maintainer feedback before implementation work is split into follow-up PRs.
Choose revision-suffixed identity for every Git checkout, clarify system dependencies, and document correction releases. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4fe65aa5-d620-4856-a525-e32bf98c16b1
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
Suppressed comments (2)
Guide/src/dev_guide/contrib/openvmm_release_proposal.md:127
- The placeholder
<9-character-commit>doesn’t follow the Guide’s documented placeholder convention (<SCREAMING_SNAKE_CASE>). Using a stable name like<SHORT_COMMIT>is also easier to reference consistently across docs and code.
**Proposal:** A normal Git checkout reports
`<VERSION>+g<9-character-commit>`, identified as a development build.
Guide/src/dev_guide/contrib/openvmm_release_proposal.md:5
- This page lives under
Guide/src/but is not referenced fromGuide/src/SUMMARY.md, so mdbook will not render/publish it and it will be effectively orphaned after merge. If the intent is to keep the RFC out of published Guide navigation, consider moving it outsideGuide/src/(e.g. a repo-levelrfcs/area). If it should be part of the Guide, add it toSUMMARY.mdunder the appropriate section (and mark it clearly as an RFC in the title).
# OpenVMM Standalone Source Release Proposal
This page proposes how OpenVMM should identify builds and publish standalone
source releases for Linux distributions.
Record that Git-free builds need only the committed product version initially and that another source-commit surface can be added later if needed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4fe65aa5-d620-4856-a525-e32bf98c16b1
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
Suppressed comments (5)
Guide/src/dev_guide/contrib/openvmm_release_proposal.md:146
- The PR description indicates Git-free source trees reporting plain
<VERSION>is already a confirmed decision, but this section is still labeled "Proposed direction". Aligning the status label with the PR description would keep the RFC’s decision tracking consistent.
**Status: Proposed direction**
Guide/src/dev_guide/contrib/openvmm_release_proposal.md:171
- The PR description says the "no
OPENVMM_PKGVERSIONoverride" decision is confirmed, but this section still says "Proposed direction". Updating the status label would prevent ambiguity for downstream readers.
**Status: Proposed direction**
Guide/src/dev_guide/contrib/openvmm_release_proposal.md:189
- The PR description lists limiting identity integration to
-V/--versionas already confirmed, but this section is still marked "Proposed direction". Consider updating the status label to reflect the described consensus.
**Status: Proposed direction**
Guide/src/dev_guide/contrib/openvmm_release_proposal.md:200
- The PR description indicates manual draft publication is already a confirmed decision, but this section still labels it as "Proposed direction". Aligning the status label with the PR description would make the RFC’s state clearer.
**Status: Proposed direction**
Guide/src/dev_guide/contrib/openvmm_release_proposal.md:112
- The PR description lists the canonical product version location as a decision already confirmed by maintainer feedback, but this section still marks it as "Proposed direction". Consider updating the status label to match the PR’s stated consensus to avoid confusing readers about what’s still under discussion.
This issue also appears in the following locations of the same file:
- line 146
- line 171
- line 189
- line 200
**Status: Proposed direction**
## Summary - document private vulnerability reporting and MSRC-owned coordinated disclosure - define case-by-case advance sharing with qualified downstream security teams - describe simultaneous publication of the public fix, patch-version source release, advisory, and CVE - keep internal repository, build, deployment, and customer-operational details out of the public guide ## Context This is a draft policy for team and downstream consensus. It assumes the source-only, manually published standalone release model proposed in #4150; it does not add or change release implementation. ## Questions for reviewers - Are the eligibility and handling rules for advance patch sharing sufficiently strict and clear? - Is the incident-specific hosted-service deployment exception appropriate? - Is the patch-version release and supported-version language the right public commitment? Co-authored-by: Ben Hillis <benhill@ntdev.microsoft.com> Copilot-Session: 4fe65aa5-d620-4856-a525-e32bf98c16b1
| `pkg-config`, and Protocol Buffers compiler. OpenHCL, test, and firmware assets | ||
| from `openvmm-deps` are outside this build. |
There was a problem hiding this comment.
Should we exclude the openhcl/ folder from the source archive? And maybe other bits too?
There was a problem hiding this comment.
Yep we could, let me see if there's a clean way to do this. We could also defer this to later if it makes things too complicated right now.
There was a problem hiding this comment.
We should be able to build openvmm without the openhcl folder present, but i suppose it might cause some weirdness if our root Cargo.toml is still referencing it...
| **Proposal:** A normal Git checkout reports | ||
| `<VERSION>+g<9-character-commit>`, identified as a development build. | ||
|
|
||
| This distinguishes commits made after the latest release even while the |
There was a problem hiding this comment.
Can we also include a dirty marker, to distinguish between clean checkouts and non?
There was a problem hiding this comment.
Good call, let's do this.
|
|
||
| The published archive necessarily lacks `.git`, so the committed Cargo version | ||
| is the only identity available. | ||
|
|
||
| The initial binary identity does not separately expose the source commit for a | ||
| Git-free build. The release tag, target, and provenance identify the published | ||
| source, and another binary surface can be added later if needed. | ||
|
|
||
| This classification is descriptive, not proof that arbitrary Git-free source | ||
| is official. Consumers must verify the source archive's checksum and | ||
| provenance attestation. | ||
|
|
There was a problem hiding this comment.
I vote for the proposal and against the alternative, for the reasons already given in the text
|
|
||
| This makes the version available to Cargo and to downstream builders without | ||
| requiring Git metadata. | ||
|
|
||
| ### 2. Development-build identity |
There was a problem hiding this comment.
We should make sure there's a check in the release workflow that a given version number hasn't already been released.
There was a problem hiding this comment.
Yep that's already there.
| differently unless every packager reproduces the release environment. | ||
|
|
||
| ### 5. Distribution package override | ||
|
|
||
| **Status: Proposed direction** | ||
|
|
||
| **Proposal:** Do not add a package-version override. The OpenVMM binary reports | ||
| the committed product version, while a distribution records its package | ||
| revision in its own package metadata. | ||
|
|
||
| This is independent of release identity. Builds from the published archive | ||
| already recover the committed Cargo version without an environment variable. | ||
|
|
There was a problem hiding this comment.
I vote for the proposal and against the alternative, for the reasons already given in the text
| and is not required to build an official source archive. | ||
|
|
||
| ### 6. Identity integration surfaces | ||
|
|
||
| **Status: Proposed direction** | ||
|
|
There was a problem hiding this comment.
I'd be fine with doing windows VERSIONINFO now to match the cargo version, but I'm ok with holding off too. The rest I think warrant more discussion.
There was a problem hiding this comment.
yeah having the windows version info match cargo version (probably with an extra .0 because windows versions are 4 numbers).
| Generated workflow files would land with the Flowey source that produces them. | ||
| Each phase would remain buildable and testable before the next phase begins. | ||
|
|
||
| ## Review guidance |
There was a problem hiding this comment.
Even if there are, nothing stops maintainers from changing the cargo version themselves.
| They should be added only when their consumers and value are clear. | ||
|
|
||
| ### 7. Manual draft publication | ||
|
|
||
| **Status: Proposed direction** | ||
|
|
||
| **Proposal:** A manually dispatched workflow creates a draft GitHub release. | ||
| A maintainer reviews the ordinary GitHub draft and clicks **Publish release**, | ||
| which creates the tag at the workflow's pinned commit. |
There was a problem hiding this comment.
I think I prefer the proposed option here, it feels to me like it's keeping more things automated, and therefore less can go wrong.
There was a problem hiding this comment.
yep agree.
Adds the reusable release-publication primitives needed by the standalone OpenVMM source release described in #4150. - makes release notes and existing-release handling explicit - allows callers to require validation/attestation side effects before publication - distinguishes a missing release from `gh` authentication or server failures - adds a reusable `actions/attest@v4` Flowey node - preserves the existing VmgsTool draft, `TODO` notes, and skip-existing behavior This is independent of the build identity work in #4162 and does not yet add the OpenVMM publication workflow. --------- Co-authored-by: Ben Hillis <benhill@ntdev.microsoft.com> Copilot-Session: 4fe65aa5-d620-4856-a525-e32bf98c16b1
Purpose
Record maintainer consensus on the standalone OpenVMM source-release model before the remaining implementation is split into reviewable changes.
This PR intentionally contains one proposal page and no implementation or generated workflow changes.
Decisions confirmed by feedback
[workspace.package] versionVERSION+g<SHORT_COMMIT>as a development buildOPENVMM_PKGVERSIONpackage override-Vand--versionopenvmm-depsImplementation
The first independently reviewable implementation slice is #4162. The remaining archive, distribution-gate, release plumbing, and publication changes will follow as separate PRs.
A feasibility prototype remains available at benhillis#12, but it is not the intended upstream landing shape.
This proposal page is intentionally not added to Guide navigation while it remains an RFC.