1

初めてのパッチ投稿(体験談）

Tetsuyuki Kobayashi

2

初めてのパッチ投稿

● 体験談です。正解とは限りません。● LinuxカーネルとU-Boot

● mailing listでパッチをやり取りする方法

– AndroidのAOSPではgerritというWebベースのツールを使うらしい

● 初投稿は2012年6月。LTSIのMLへ。

Who am I?● 20+ years involved in embedded systems

● 10 years in real time OS, such as iTRON● 10 years in embedded Java Virtual Machine● Now GCC, Linux, QEMU, Android, …

● Blogs● http://d.hatena.ne.jp/embedded/ (Personal)● http://blog.kmckk.com/ (Corporate)● http://kobablog.wordpress.com/(English)

● Twitter● @tetsu_koba

4

LinuxCon JapanでのGregさんの話

● http://events.linuxfoundation.org/images/stories/pdf/lcjp2012_kh_maintainer.pdf● パッチのべからず集

5

パッチを投稿で重要なこと

●内容●書式、送り方●誰に送るか？

教えてくれる人がいないときつい。

当然。

6

メイル環境の整備

● 予想外に手間どった● パッチの送信にThunderbirdは不向き

● それ以外の読み書きには使用できる。● 結論で言えば、まずgit send-emailが使

えるようにすべし。

7

パッチ投稿の注意点

● 内容はともかく、フォーマットについて● 添付ファイル禁止

● パッチがあたらなくなるような余計な変換禁止(メイルソフトの余計なお世話)● 余計な改行● タブをスペースに変換したり

● スレッドを途切らせない。

● checkpatch.pl スクリプトで確認する。

● メンテナは一日に数百のパッチを処理する。厳格なルールはそのためのもの。

8

git format-patch

● コミットの内容をメールの形式にしてくれる。● -s オプションでSigned-off-byの行を追加

● --cover-letter オプションで複数パッチの表紙作成

● --subject-prefix=”PATCH v2” v2以降のパッチのとき

9

git imap-send● imapのメールの下書きのフォルダに送信できる。

それを編集して投稿。

● Firefoxではメールを編集したときに、message IDが上書きされ、In-Reply-Toは消されてしまう。うまくいかない。

● お奨めしない。

10

git send-email● SMTPサーバと通信してメールを送信してくれる。

● In-Reply-Toの指定可。

● PATCH Seriesの扱いも簡単。

● パッチの投稿にはこれを使うべし。

● git format-patchでファイルに書き出し→ そのファイルを編集 → git send-emailで送信。

11

git send-emailの設定

● Gmailのアカウントを使うならば簡単。git send-email単体で可能。

● 私の場合は会社のアカウントを使いたかった。なかなかうまくいかない。msmtpを経由したらできた。

● 最悪の場合でも、Gmail経由で送信しつつ、Fromは別名にする方法がある。● Gmailのアカウントの設定で別名を登録しておく。

12

コマンドの使用例

$ git format-patch -s -3 --subject-prefix="PATCH v2" --cover-letter -o /tmp/patch001

$ scripts/checkpatch.pl /tmp/patch001/00*.patch

パッチの個数 出力先のディレクトリ

0000-cover-letter.patch はエラーになるが気にしない。

$ git send-email --in-reply-to=__ --thread --to=__ --cc=__ /tmp/patch001/00*.patch

テキストエデュタで内容を編集。

メッセージID

例: 1347599285-11830-1-git-send-email-koba@kmckk.co.jp

13

誰に送るか？

● メイルの流量が多いので単にML宛てに送るだけだと必要な人から見逃される可能性がある。

● To: にメンテナ or Custodian● (パッチを取り込むというアクションをする人。）● カテゴリごとに異なる● http://www.denx.de/wiki/U-Boot/Custodians

● Cc: にレビューして欲しい人とML● 慣れればわかる。神経質にならなくてもＯＫ。

実際にやってみて

● パッチはそのままで受理されることは少ない。2回くらいの書き直しは当たり前。● 更新したパッチの投稿のしかた● http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions

● [RFC]はRequest For Comment。意見求む。● 逆にこのパッチをこのまま受理して欲しいわけではない

という意味にもなる。

● 人間同士のやりとり。● 英語の良し悪しは気にするな。

15

MLに参加しよう

● パッチを投稿する以外にもできることはある。● バグ報告

● 最新版だと起動しないなど。● エラーログを添えて。

● パッチのレビュー● Acked-by name <addr>● 賛意の表明。(イイネ！)

● パッチのテスト ● Tested-by name <addr>

お奨め

MLのアーカイブ

● LKML● http://www.spinics.net/lists/kernel/

● ARM Kernel● http://lists.infradead.org/pipermail/linux-arm-kernel/

● Linux SH● http://www.spinics.net/lists/linux-sh/

● LTSI● http://lists.linuxfoundation.org/pipermail/ltsi-dev/

● U-Boot● http://lists.denx.de/pipermail/u-boot/

17

実例

● [PATCH] arm: bugfix: save_boot_params_default accesses uninitalized stack when -O0● [PATCH] arm: bugfix: save_boot_params_default accesses uninitalized stack when -O0● [RFC][PATCH] net: nfs: extend NFS_TIMEOUT● [RFC][PATCH] net: nfs: make NFS_TIMEOUT configurable