docs: 交付总账 v1.0 —— 补记 #735/#736,并写明为什么不是单 PR - #303
Merged
Conversation
设计文档此前停在 #734,漏掉最后两个 PR,而它们恰好含本轮最可迁移的发现。
§11.1 完整变更集:八个 PR 两个仓,标出哪三个是回归修复。
§11.2 为什么不是单 PR。两条是硬约束、一条是我的失误,分开写:
- 跨仓:一个 PR 无法跨两个 GitHub 仓库,而 §10.9 已论证这个切分是两个索引
各做各建模的事;
- 发布顺序:#301 的脚本从**已发布索引**解析 compat.libinput,只能在 #298
合入并发布产物之后才可能被验证;
- #733/#735 本可以不存在——它们修的是 #732 的回归,靠自我 review 而非新信息
找到,所以合 #732 之前跑完检查清单就都在 #732 里了。清单是被这两次回归逼
出来的,代价就是规则从事故里学、而事故已进历史。
§11.3 libs/** 三处缺席:前两处漏评审覆盖,第三处漏**交付**——#735 合了全绿、
镜像同步到位,xlings update 仍在发修复前那一版。这解释了本轮四处问题为什么
全部靠自我 review 发现、没有一处是 CI 抓到的。
§11.4 加一行 DISCOVERY = 三项检查,两项分别被 #733/#735 逼出来。
§11.5 最终状态,含用户侧产物核验(xim-index-ea36f6b.tar.gz)与两份数据归档
的双镜像 sha256 一致性。
头部状态从「待 review」改为「已实现并闭环验证(v1.0)」。
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.
设计文档此前停在 #734,漏掉最后两个 PR —— 而它们恰好含本轮最可迁移的发现。这是「验证全部更新到文档」的实缺,本 PR 补齐并给出交付总账。
§11.1 完整变更集
八个 PR,两个仓,全部已合入。标出哪三个是回归修复而非功能:
§11.2 为什么不是单 PR —— 两条硬约束,一处我的失误
分开写,不混为一谈:
硬约束一:跨仓。 一个 GitHub PR 无法跨两个仓库。而 §10.9 已论证这个切分本身是正确的 —— mcpp-index 打包代码,xim 发布数据目录与运行期发现变量,两个索引各做各建模的事。正是这条约束决定了这套东西必须至少两个 PR。
硬约束二:发布顺序。 #301 的沙箱脚本从已发布索引解析
compat.libinput(它只声明一个索引键),所以只能在 #298 合入并且索引产物发布之后才可能被验证。合成一个 PR 会让脚本引用一个还不存在的包。我的失误:#733 与 #735 本可以不存在。 它们修的是 #732 引入的回归,而找到它们靠的是自我 review 而非新信息 —— 也就是说,如果我在合 #732 之前就跑完那份检查清单,两处都会在 #732 里。清单本身是被这两次回归逼出来的,这正是代价:规则从事故里学,而事故已经进了历史。
§11.3
libs/**三处缺席ci-test.ymlci-xpkg-test.ymlpublish-artifact.yml第三处最隐蔽:#735 合进 main、11 个检查全绿、gitee 镜像同步到
ea36f6b,而xlings update仍在发xim-index-f1702a1.tar.gz。「合了、绿了、用户拿到的还是旧的」骗过了每一个常规检查。这解释了本轮四处问题为什么全部靠自我 review 发现、没有一处是 CI 抓到的 —— CI 从来没有机会看那个文件。
§11.4 加一行 DISCOVERY = 三项检查
两项分别被 #733 / #735 逼出来:放置+声明两个调用、回头看每个
declare_subos_env调用点、回头看consumer_envs()的消费者。§11.5 最终状态
xim-index-ea36f6b.tar.gz(含全部修复)头部状态从「待 review」改为「已实现并闭环验证(v1.0)」。