docs: close the development-guide gaps the 2.0.2 release exposed - #33
Open
mattmacrocket wants to merge 1 commit into
Open
docs: close the development-guide gaps the 2.0.2 release exposed#33mattmacrocket wants to merge 1 commit into
mattmacrocket wants to merge 1 commit into
Conversation
Three things the guide did not say, each of which cost time during the 2.0.2 release. The Local builds table listed only `bash scripts/build-pkg.sh`, which produces a package you cannot install without the Developer ID identities, because the postinstall requires the helper to satisfy the release designated requirement. The mode that produces something a developer can actually install, and the one-time opt-in it needs, were documented only in the release notes. Added both, including that the opt-in authorizes one attempt rather than one success. The release section said to dispatch Release Sensor before Release Home Distribution. Release Sensor has never been dispatched and currently fails closed: it runs check-linux-release-boundary.py and linux_release.mode is blocked. A macOS Home release only needs the sensor tag to exist, not a published sensor release, so the guide now says that and points at the review decision required to unblock the sensor path rather than leaving someone to edit the policy to make a release pass. The component-tag requirement was implied by the numbered list but not stated as a precondition. Dispatching without app-vX.Y.Z and sensor-vX.Y.Z fails in the verify job with a message that does not name the missing tag, which is exactly how the first 2.0.2 dispatch failed. Recorded the error text so the next person can search for it, plus the -s requirement and the fact that the tag ruleset blocks deletion, so a tag pointed at the wrong commit cannot be repaired. Also fixed a dangling reference: the functional test plan pointed at qa/FINDINGS.md, which PR 31 untracked and gitignored. It now says the file is local-only and why. Dropped the stale branch line while there, since that branch is merged.
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
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
1 participant
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.
Summary
Three gaps in
docs/DEVELOPMENT.md, each of which cost time during the 2.0.2 release, plus one dangling reference.Not urgent. 2.0.2 is published and unaffected.
1. No documented way to build an installable package
The Local builds table listed only
bash scripts/build-pkg.sh. That produces a package you cannot install unless you hold the Developer ID identities, because the postinstall requires the helper to satisfy the release designated requirement.SQUIRRELOPS_LOCAL_TEST_BUILD=1is the mode that produces something a developer can install, and it was documented only in the release notes.Added it, along with the one-time opt-in and the fact that the opt-in authorizes one attempt rather than one success.
2. The sensor release instruction does not match reality
The guide said to dispatch
Release SensorbeforeRelease Home Distribution.Release Sensorhas never been dispatched and currently fails closed: it runsscripts/check-linux-release-boundary.py, andlinux_release.modeisblocked.A macOS Home release only needs
sensor-vX.Y.Zto exist as a tag, not a published sensor release. The guide now says that, and points at the review decision required to unblock the sensor path rather than leaving someone to edit the policy to make a release pass.3. The component-tag precondition was implied, not stated
Dispatching without
app-vX.Y.Zandsensor-vX.Y.Zfails in the verify job with:which does not name the missing tag. That is how the first 2.0.2 dispatch failed. Recorded the error text so it is searchable, plus the
-srequirement (tag.gpgsignis unset here) and the fact that the tag ruleset restricts deletion, so a tag pointed at the wrong commit cannot be moved.4. Dangling reference
qa/FUNCTIONAL-TEST-PLAN.mdpointed atqa/FINDINGS.md, which PR #31 untracked and gitignored. It now says the file is local-only and why. Dropped the stale branch line while there, since that branch is merged.Verification
Every claim checked against the tree rather than written from memory:
SQUIRRELOPS_LOCAL_TEST_BUILDpresent inscripts/build-pkg.shlinux_release.modeisblockedin.github/release-policy.jsoncheck-linux-release-boundary.pyraises onblocked, and is invoked atrelease-sensor.yml:83tag.gpgsignunsetrelease-sensor.ymlhas zero runs in historyDocs only, no code changes. Package and supply-chain tests still pass (57).