How to post patch to ML. (written in Japanese)

1. 初めてのパッチ投稿(体験談）
Tetsuyuki Kobayashi
1

2. 初めてのパッチ投稿
● 体験談です。正解とは限りません。
● LinuxカーネルとU-Boot
● mailing listでパッチをやり取りする方法
– AndroidのAOSPではgerritというWeb
ベースのツールを使うらしい
● 初投稿は2012年6月。LTSIのMLへ。
2

3. 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
● パッチのべからず集
4

5. パッチを投稿で重要なこと
●
内容 当然。
●
書式、送り方 教えてくれる人が
●
誰に送るか？ いないときつい。
5

6. メイル環境の整備
● 予想外に手間どった
● パッチの送信にThunderbirdは不向き
● それ以外の読み書きには使用できる。
● 結論で言えば、まずgit send-emailが使
えるようにすべし。
6

7. パッチ投稿の注意点
● 内容はともかく、フォーマットについて
● 添付ファイル禁止
● パッチがあたらなくなるような余計な変換禁止(メイルソ
フトの余計なお世話)
● 余計な改行
● タブをスペースに変換したり
● スレッドを途切らせない。
● checkpatch.pl スクリプトで確認する。
● メンテナは一日に数百のパッチを処理する。厳格な
ルールはそのためのもの。
7

8. git format-patch
● コミットの内容をメールの形式にしてくれる。
● -s オプションでSigned-off-byの行を追加
● --cover-letter オプションで複数パッチの表紙
作成
● --subject-prefix=”PATCH v2” v2以降のパッ
チのとき
8

9. git imap-send
● imapのメールの下書きのフォルダに送信できる。
それを編集して投稿。
● Firefoxではメールを編集したときに、message ID
が上書きされ、In-Reply-Toは消されてしまう。うま
くいかない。
● お奨めしない。
9

10. git send-email
● SMTPサーバと通信してメールを送信してくれる。
● In-Reply-Toの指定可。
● PATCH Seriesの扱いも簡単。
● パッチの投稿にはこれを使うべし。
● git format-patchでファイルに書き出し→ そのファ
イルを編集 → git send-emailで送信。
10

11. git send-emailの設定
● Gmailのアカウントを使うならば簡単。git send-
email単体で可能。
● 私の場合は会社のアカウントを使いたかった。なか
なかうまくいかない。msmtpを経由したらできた。
● 最悪の場合でも、Gmail経由で送信しつつ、From
は別名にする方法がある。
● Gmailのアカウントの設定で別名を登録しておく。
11

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
12

13. 誰に送るか？
● メイルの流量が多いので単にML宛てに送る
だけだと必要な人から見逃される可能性があ
る。
● To: にメンテナ or Custodian
● (パッチを取り込むというアクションをする人。）
●
カテゴリごとに異なる
● http://www.denx.de/wiki/U-Boot/Custodians
● Cc: にレビューして欲しい人とML
● 慣れればわかる。神経質にならなくてもＯＫ。
13

14. 実際にやってみて
● パッチはそのままで受理されることは少ない。2回く
らいの書き直しは当たり前。
● 更新したパッチの投稿のしかた
● http://www.denx.de/wiki/view/U-Boot/Patches#Sending_
● [RFC]はRequest For Comment。意見求む。
●
逆にこのパッチをこのまま受理して欲しいわけではない
という意味にもなる。
● 人間同士のやりとり。
●
英語の良し悪しは気にするな。

15. MLに参加しよう
● パッチを投稿する以外にもできることはある。
● バグ報告
● 最新版だと起動しないなど。
● エラーログを添えて。
● パッチのレビュー
● Acked-by name <addr>
● 賛意の表明。(イイネ！)
お奨め
● パッチのテスト
● Tested-by name <addr>
15

16. 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 ac
● [PATCH] arm: bugfix: save_boot_params_default ac
● [RFC][PATCH] net: nfs: extend NFS_TIMEOUT
● [RFC][PATCH] net: nfs: make NFS_TIMEOUT confi
17