RFC: standalone OpenVMM source releases - #4150
Closed
Ben Hillis (benhillis) wants to merge 7 commits into
Closed
Conversation
added 4 commits
August 3, 2026 21:26
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
Contributor
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.
This was referenced Aug 4, 2026
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
Contributor
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
This was referenced Aug 5, 2026
Contributor
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**
Ben Hillis (benhillis)
added a commit
that referenced
this pull request
Aug 5, 2026
## 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
Comment on lines
+89
to
+90
| `pkg-config`, and Protocol Buffers compiler. OpenHCL, test, and firmware assets | ||
| from `openvmm-deps` are outside this build. |
Contributor
There was a problem hiding this comment.
Should we exclude the openhcl/ folder from the source archive? And maybe other bits too?
Member
Author
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.
Contributor
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 |
Contributor
There was a problem hiding this comment.
Can we also include a dirty marker, to distinguish between clean checkouts and non?
Member
Author
There was a problem hiding this comment.
Good call, let's do this.
Comment on lines
+150
to
+161
|
|
||
| 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. | ||
|
|
Contributor
There was a problem hiding this comment.
I vote for the proposal and against the alternative, for the reasons already given in the text
Comment on lines
+117
to
+121
|
|
||
| This makes the version available to Cargo and to downstream builders without | ||
| requiring Git metadata. | ||
|
|
||
| ### 2. Development-build identity |
Contributor
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.
Member
Author
There was a problem hiding this comment.
Yep that's already there.
Comment on lines
+167
to
+179
| 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. | ||
|
|
Contributor
There was a problem hiding this comment.
I vote for the proposal and against the alternative, for the reasons already given in the text
Comment on lines
+185
to
+190
| and is not required to build an official source archive. | ||
|
|
||
| ### 6. Identity integration surfaces | ||
|
|
||
| **Status: Proposed direction** | ||
|
|
Contributor
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.
Member
Author
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 |
Contributor
There was a problem hiding this comment.
Even if there are, nothing stops maintainers from changing the cargo version themselves.
Comment on lines
+196
to
+204
| 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. |
Contributor
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.
Member
Author
There was a problem hiding this comment.
yep agree.
Ben Hillis (benhillis)
added a commit
that referenced
this pull request
Aug 7, 2026
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
Ben Hillis (benhillis)
added a commit
that referenced
this pull request
Aug 10, 2026
## Purpose Implement the product-version and build-identity portion of #4150 as an independently reviewable first slice. ## Behavior - store the canonical OpenVMM product version in root `[workspace.package] version` - keep that value at the most recently released version until a reviewed change selects another version - report `VERSION+g<9-character commit>` for every clean Git checkout, including an exact release-tag checkout - append `.dirty` when a checkout has staged or unstaged tracked changes - report plain `VERSION` for a Git-free source tree - expose concise identity through `-V` and detailed identity through `--version` - use `MAJOR.MINOR.PATCH.0` from the Cargo product version for Windows `VERSIONINFO` The detailed form includes the build kind, canonical product version, full Git revision when available, and build target. ## Implementation - add `openvmm_build_info` to resolve identity at compile time - reject Git metadata inherited from a parent repository - watch Git identity and tracked worktree files without causing perpetual Cargo rebuilds - derive Windows executable resources directly from `CARGO_PKG_VERSION` - make the versioned crates explicitly non-publishable - update the package-info house rule and CLI reference ## Out of scope This PR intentionally contains no source-archive assembly, distribution-build gate, release workflow, provenance, packaging guide, telemetry, saved-state metadata, or additional binary metadata surfaces. Those will be separate follow-up PRs after this behavior is accepted. ## Validation - targeted `cargo check`, `cargo clippy --all-targets`, `cargo doc --no-deps`, and unit tests for the affected OpenVMM and Flowey packages - `cargo xtask fmt --fix` - Flowey workflow regeneration - repeated no-op builds confirm `openvmm_build_info` remains fresh --------- Co-authored-by: Ben Hillis <benhill@ntdev.microsoft.com> Copilot-Session: 0ba1c0df-faf0-4a0e-b39d-c3eb0e363fce Copilot-Session: 4fe65aa5-d620-4856-a525-e32bf98c16b1
Three of the five phases have merged since this page was written, so the
page described as future work things the tree already does, and marked
decisions as open that shipped behavior now depends on.
Mark the decisions a merged phase implements, record the phase status
and the order phases actually landed in, and say plainly that revisiting
an implemented decision means changing shipped behavior.
Also correct the archive name to openvmm-<VERSION>.tar.gz. It was
renamed during source assembly review so that the filename and the root
directory both match %{name}-%{version}, and this page was the last
place carrying the old name.
Contributor
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 (1)
Guide/src/dev_guide/contrib/openvmm_release_proposal.md:4
- This new Guide page isn’t referenced from
Guide/src/SUMMARY.md(or any other Guide page), so it will be orphaned in the rendered mdBook and hard to discover/review later. If the intent is to keep it “RFC-only” for now, consider adding it under the Contributing section (possibly marked as RFC) or linking to it from an existing contrib page (e.g.dev_guide/contrib/release.md).
# OpenVMM Standalone Source Release Proposal
This page proposes how OpenVMM should identify builds and publish standalone
source releases for Linux distributions.
Ben Hillis (benhillis)
added a commit
that referenced
this pull request
Aug 12, 2026
…4200) ## Purpose Add the source-archive and distribution-build portion of #4150, now that the build identity contract from #4162 has landed. Linux distributions build OpenVMM from a source tarball rather than from a git checkout, using distribution-provided native dependencies. Nothing in the repo produced such a tarball, and nothing proved OpenVMM could be built from one. This adds both, and gates the result in CI so the distribution build path cannot silently regress. ## Assembling the archive - assemble `openvmm-<VERSION>.tar.gz` from the tracked tree at `HEAD`, unpacking into `openvmm-<VERSION>/` - make repeated assembly deterministic with a fixed archive mode mask and `gzip -n` - produce `SHA256SUMS` - reject checkouts with tracked modifications, and identity/version mismatches - transfer archive identity through typed Flowey artifact metadata The archive name and its root directory both match `%{name}-%{version}`, so RPM's `%autosetup` and Fedora's forge macros need no override. ## Gating the distribution build - extract outside the checkout and build OpenVMM using distribution-provided native dependencies - run the distribution build in normal PR and CI gates The build uses system `protoc`, OpenSSL, compiler/linker, Linux headers, and `pkg-config`; it deliberately does not restore `.packages/` or `openvmm-deps`. ## Documentation Add a Linux packaging guide covering archive identity, checksum verification, build requirements and their distribution package names, offline vendoring, RPM/Debian integration requirements, package versioning, and expected runtime dependencies. ## Out of scope Publication, GitHub releases, attestations, release preparation, and maintainer release procedures remain separate follow-up work. Nothing currently uploads the assembled archive as a release asset; the node is shared so that the future release pipeline ships the exact bytes CI already builds. OpenVMM does not yet publish an OpenPGP signature alongside the archive, so `uscan` signature verification is unavailable to Debian packagers. That needs a signing-key decision and is left to the publication work. ## Validation - `cargo xtask fmt --fix`, including flowey pipeline regeneration - targeted `flowey_lib_hvlite` tests - targeted clippy and `cargo doc` - Guide test and build - assembled the archive from a scratch repo and confirmed byte-identical output across runs --------- Co-authored-by: Ben Hillis <benhill@ntdev.microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4fe65aa5-d620-4856-a525-e32bf98c16b1 Copilot-Session: ce417d1e-c8d7-4cf9-9292-5db77d7f3758
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Record maintainer consensus on the standalone OpenVMM source-release model.
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 status
Implementation is proceeding in separately reviewed phases. Three have merged, so several of the decisions above are no longer hypothetical:
Phases landed out of numeric order: the generic release helpers were reviewable on their own and merged before source assembly.
Because phases 1, 2, and 4 have merged, revisiting decisions 1-6 now means changing shipped behavior rather than choosing a direction. Decision 7, manual draft publication, is the one whose implementation has not yet merged.
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.