Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Replacing a single patch in a series to reduce review overhead

オープン
#633 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
python
領域
backend

調査の方向性

まず、Patchwork がメールヘッダーをどのように解析し、パッチをシリーズに関連付けているかを追跡し、次に、置き換えのケースについてリンク先の libc-alpha スレッドを確認します。標準の Supersedes または Obsoletes ヘッダーでパッチの置き換えを識別でき、依存する自動テストフレームワークが更新されたシリーズを認識できるようになれば、変更は完了です。

索引モデルが issue の本文から書いたものです。

説明

It is reasonably common that a small error in a single patch in a long series can be fixed with minimal effort. In that case, resubmitting the series is a huge, unnecessary overhead on reviewers.

For myself, I generally tend to submit such patches with a header like:

[PATCH v5.1 10/12] ...

... as a reply to (In-Reply-To: set to), in this case, [PATCH v5 10/12].

Patchwork does not recognize this pattern, and automatic test framework that depend on it will not operate.

Assuming that recognizing this pattern automagically is not practical, the standard email header "Supersedes:" (alias "Obsoletes:") could be supported to indicate that a patch is intended to replace a previous version in a series.

As one concrete example, see this email thread:

https://inbox.sourceware.org/libc-alpha/20250514221405.471472-13-hpa@zytor.com/

In this case the patch being replaced is 12/12.

主要言語
Python
スター
317
フォーク
91
30日以内にマージされた PR はありません

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

getpatchwork/patchwork のほかの issue

getpatchwork/patchwork の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。