QuantEcon / QuantEcon/lecture-python-programming

Publishing is a manual tag push, and the drift is what produced yesterday's 404s

未关闭
#591 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

maintenance
主要语言
JavaScript
星标
72
派生
31
平均合并
2 天 20 小时
30 天内合并 PR
8

描述

The pattern

Every repository in this series publishes only when someone pushes a publish* tag — this repo and the .fa, .fr and .zh-cn editions alike. Merging to main changes nothing a reader can see.

That is a deliberate design and it has real merits: publishing is expensive, and a manual gate means someone decides when the site changes. But the gate is currently the only thing scheduling publication, and in practice it drifts. State as of this morning, before today's round of tags:

Repository Last published Days stale
lecture-python-programming 2026-07-16 18
.fa 2026-06-19 45
.fr 2026-07-17 17
.zh-cn 2026-06-19 45

This repo had three lecture-affecting commits on main that no reader could see.

What that drift actually cost

Three things surfaced yesterday that all trace back to it, and none of which looked like a publishing problem at first:

polars 404'd in every language for four days. Added here on 2026-07-30 in #408, synced to all three translated editions and merged into each within the hour. Content and _toc.yml entries were correct everywhere. It was still 404 on all four sites — including this one — purely because nothing had been tagged since. The first read of that evidence was "the translations have not caught up", which was wrong; the English site did not have it either.

A wrong canonical stayed live for 45 days. The .zh-cn edition was emitting the English URL as its canonical on every page, telling search engines the entire Chinese edition was a duplicate of this one. Fixed in .zh-cn#80, but the fix only reached readers when that edition was finally tagged.

Divergence windows are set by tag timing, not translation speed. Sync PRs across all three editions merge in 8 minutes to 2 days, nearly always within the hour. Publishing lags by weeks. So when the language switcher advertises a page some edition does not have, the gap is almost entirely publish cadence — an inversion of the assumption I first wrote up in QuantEcon/action-translation#239, which had to be rewritten after measuring.

Yesterday's round is the counter-example: all four editions were tagged within about two minutes, all four builds succeeded in roughly six, and the switcher, the canonical fixes and polars all landed everywhere simultaneously. No divergence window opened at all. That is what good looks like, and it happened because someone did four things by hand in one sitting.

Worth considering

Not a concrete proposal — the right answer depends on how much manual control you want to keep:

  • Publish on merge to main, with the tag retained for deliberate re-publishes. Maximum freshness, least control.
  • Scheduled publish — a weekly or nightly cron that tags if main has moved. Bounds staleness without publishing on every merge.
  • Keep it manual but make drift visible — a check that opens or comments on an issue when main is more than N days or M commits ahead of the last publish tag. Cheapest, and it addresses the actual failure, which is that nobody knew.
  • Whatever is chosen, coordinate the editions. The translated sites should publish close to this one. Their content is usually ready within the hour; it is the tags that spread them weeks apart.

The last point is the one I would weight most. The individual staleness is survivable; the editions drifting apart is what produces reader-visible breakage now that they cross-link.

Related

  • QuantEcon/action-translation#239 — asks for a check that detects switcher and hreflang targets returning 404. Largely a symptom of this; worth less if publishing becomes regular.
  • QuantEcon/quantecon-book-theme#421 — language-aware 404 page, which softens the reader-facing half of the same window.

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

未指定文件、测试或工作流入口点。首先检查当前 publish* 标签如何在此仓库以及 .fa、.fr 和 .zh-cn 版本中触发发布,然后比较合并、调度和漂移检测选项。完成的标准是:形成一项达成一致的策略和协调一致的行为,将所有版本的滞后程度控制在一定范围内。

由索引模型根据 Issue 内容生成。

评估

技术栈
git, github
领域
ci-cd, release
Issue 类型
功能
难度
5/5
预计耗时
一周以上
活跃度
冷清
描述清晰度
需要澄清
新手友好度
35/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。