Skip to content

fix(latex): correct the observed pull request count - #160

Open
toshi0806 wants to merge 1 commit into
mainfrom
correct-the-observed-pull-request-count
Open

fix(latex): correct the observed pull request count#160
toshi0806 wants to merge 1 commit into
mainfrom
correct-the-observed-pull-request-count

Conversation

@toshi0806

Copy link
Copy Markdown
Member

#158latex.json の description に書いた観測値が誤っていたので直します。1 行です。

-Across 2026-08-27 to 08-29 that produced nine pull requests over three repositories, ...
+Across 2026-08-27 to 08-29 that produced seven pull requests across the two repositories that carry lock files, ...

何を間違えたか

.github の 2 本を lock file maintenance として数えていました。このリポジトリに package-lock.json はありません。 lockfile が無いので lock file maintenance は起きえず、直前の段落自身が it is a no-op for repositories that have no lock file と書いています。

実体は #154 / #156smkwlab/ai-academic-paper-reviewer action を v1.20 / v1.22 に更新)で、本文の Release Notes に "lock file maintenance" の文字列が含まれていたものです。gh search prs --owner smkwlab "lock file maintenance" は全文検索なので、タイトルではなく本文にマッチしていました。

リポジトリ #158 の記述 実際
ai-academic-paper-reviewer 4 本(#76 #77 #79 #81 4 本 ✓
texlive-ja-textlint 3 本(#145 #146 #147 3 本 ✓
.github 2 本 0 本
9 本 / 3 リポジトリ 7 本 / 2 リポジトリ

結論は変わりません

7 本でも同じ問題です。決定的証拠だった「ai-academic-paper-reviewer #77#76 のマージ 36 秒後に作成された」も無傷ですし、窓を狭める根拠も、before 5am on friday という値も変わりません。訂正するのは数字だけです。

書き方も少し変えています

over three repositoriesacross the two repositories that carry lock files にしました。単に数を直すだけでなく、この観測が lockfile を持つリポジトリに限られることを明示しておけば、次に数える人が同じ間違い方をしません。直前の段落の no-op for repositories that have no lock file とも整合します。

関連

The nine counted two lock file maintenance pull requests in this
repository, which has no lock file and therefore cannot produce one --
the paragraph above says as much. They were action updates whose release
notes happened to contain the phrase, and a full-text `gh search prs`
matched on the body rather than the title.

Seven across ai-academic-paper-reviewer and texlive-ja-textlint is the
real figure, and naming the two repositories as the ones that carry lock
files makes the count checkable. The argument is unchanged.

Refs #157

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

このPRは latex.json の説明文中の観測値(PRの数とリポジトリ数)を修正するものです。PRの説明に詳細な根拠が示されており、修正内容は適切です。コードロジックへの影響はなく、ドキュメント的な記述の訂正です。特に重大な問題は見当たりません。

Comment thread latex.json
"The concurrent-PR cap throttles the same queue from the other end. Majors are never auto-merged, so they stay open until they are reviewed; under the inherited cap of ten they hold the quota and the auto-merged minor/patch lane stops being refilled -- the same starvation as above, at a different valve. The window is the only throttle either limit needs to leave in place.",
"Refresh lock files weekly, in a narrow window on the first day of the one above. Bumping direct dependencies never rewrites the rest of the tree, so advisories in transitive packages accumulate unseen -- the eleven advisories found in ai-academic-paper-reviewer were almost all transitive. Lock file maintenance carries its own schedule that the top-level one does not override, so a window has to be named here; leaving it out would fall back to Renovate's Monday-early default and split the week into two update waves. Take the shape of that default -- one day, before dawn -- and move only the day. This lives in the latex preset rather than the npm one because the window is defined here, and it is a no-op for repositories that have no lock file.",
"Keep that window narrower than the two-day one above, because the reasoning for widening does not carry here. A version update is an item that a job can exhaust; lock file maintenance is the difference between the committed lock file and the registry. Merging it restores that difference within hours, so the next job inside the window has something to create again. Across 2026-08-27 to 08-29 that produced nine pull requests over three repositories, one of them opened thirty-six seconds after its predecessor merged, each carrying a single transitive package where one weekly pull request would have carried all of them. Five hours still exceeds the four-hour job interval, so this window cannot fall between two jobs the way the Sunday evening one did. Nothing urgent rides on the cadence either: osvVulnerabilityAlerts in the default preset bypasses every schedule, which leaves lock file maintenance a routine refresh rather than the security net."
"Keep that window narrower than the two-day one above, because the reasoning for widening does not carry here. A version update is an item that a job can exhaust; lock file maintenance is the difference between the committed lock file and the registry. Merging it restores that difference within hours, so the next job inside the window has something to create again. Across 2026-08-27 to 08-29 that produced seven pull requests across the two repositories that carry lock files, one of them opened thirty-six seconds after its predecessor merged, each carrying a single transitive package where one weekly pull request would have carried all of them. Five hours still exceeds the four-hour job interval, so this window cannot fall between two jobs the way the Sunday evening one did. Nothing urgent rides on the cadence either: osvVulnerabilityAlerts in the default preset bypasses every schedule, which leaves lock file maintenance a routine refresh rather than the security net."

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✨ [POSITIVE] 修正内容は正確で、PRの説明にある表と一致しています。over three repositoriesacross the two repositories that carry lock files に変更することで、観測対象がロックファイルを持つリポジトリに限定されることが明示され、直前の段落の no-op for repositories that have no lock file との整合性も取れています。良い改善です。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant