2013年6月25日火曜日
2013年6月13日木曜日
2013年6月6日木曜日
2013年6月4日火曜日
パッチを投稿しよう！
オープンソースをダウンロードしてきて、動かしたり、改造したりしているうちに、
バグ修正や、新機能などをコミュニティへフィードバックしたくなってくるかもしれません。
自分は、最近 U-Boot によくパッチを投稿しています。
以下は、U-Boot にパッチを送り始めた時に自分がやった時の一連の流れをまとめておきます。
U-Boot は基本的に、Linux Kernel と同じ開発スタイルを踏襲しているので、それなりに参考になるかと。
たいていは、パッチはメーリングリストに投稿するようになっていると思います。
なので、まずはメーリングリストを購読します。
やり方は、開発のコミュニティのページに書いてあります。
これについては、前回、git send-email でまとめておきました。
パッチの作り方は、コミュニティのページに説明があると思います。
ログの入れ方とか、いろいろと取り決めがあるので、じっくり読みます。
Linux Kernel を始め、いくつかのコミュニティでは sign-off という制度があります。
sign-off とは、このパッチはオープンソースとして提供しても大丈夫なものですよ、ということを私が証明します、という意味だと、自分なりに理解しています。
自分が一から書いたパッチであれば当然問題はないです。
パッチの中に、別の GPL のコードを含んでいても問題はないです。
一方、GPL とは相容れないライセンスのコードを含んでいたら、NGです。
コミット時に
のようにすれば、ログに
パッチ生成時に
のようにしてもいいですが、忘れないように commit 時にやっておくのがいいように思います。
前回 はとりあえず練習で自分宛に送りましたが、いよいよ今度は本物のメーリングリストに送ります。
初めてパッチを送信する時は、結構ドキドキするものです。
毎回送信先のアドレスを聞いてこないように
の設定をします。プロジェクトごとに送信先が違うはずなので、
初回の投稿の場合、
については、そのまま [Return] でよいです。
送信するのが初めての場合、すぐにメーリングリストに配信されずに
Your message to <...> awaits moderator approval
みたいな返信が来ることがあります。
一瞬、なんじゃこりゃ？みたいに思うかもしれませんが、心配いりません。
たぶん、スパム対策のために、初めて投稿してくる人に対しては、まともな内容かどうか審査があるんだと思います。
問題なければ、数時間後にはメーリングリストに配信されてくると思います。
2回目からは、すぐにメーリングリストに配信されると思います。
パッチのステータス管理に Patchwork http://patchwork.ozlabs.org/ というシステムを使っているプロジェクトもあります。
自分のパッチもステータス New として登録されていることを確認します。
自分のパッチに対し、フィードバックしてくれる人があるかもしれません。
これに対しては、
投稿したパッチがそのまま Accepted になれば万々歳です。
Rejected になれば、基本的にはそこで終わりです。
Changes Requested になった場合は、指摘された部分を修正することで、Accepted になる可能性が高いです。
この場合、元のスレッドに対して修正版のパッチを返信するのではありません。
(Changes Requested になれば、そのスレッドは基本的に終わりです。)
新しいパッチファイルを作り直し、投稿します。
修正をしたら、
でコミットを作り直します。
そして、今度はVersion 2のパッチであることがわかるようにタイトルに入れます。
以下のようにすれば git がやってくれます。
さらに、前回のパッチからどこが変わったのかをパッチの中に書き込みます。
という行があって、この直後にコメントを入れることができます。
これは git のコミットログには反映されません。
例えば、以下のような感じです。
のところに、前回のバージョンのパッチの Message-ID（前回のメールのヘッダを見れば書いてある）を入力します。
これによって、スレッドで関連付けられます。
バグ修正や、新機能などをコミュニティへフィードバックしたくなってくるかもしれません。
自分は、最近 U-Boot によくパッチを投稿しています。
以下は、U-Boot にパッチを送り始めた時に自分がやった時の一連の流れをまとめておきます。
U-Boot は基本的に、Linux Kernel と同じ開発スタイルを踏襲しているので、それなりに参考になるかと。
ML に参加する
たいていは、パッチはメーリングリストに投稿するようになっていると思います。
なので、まずはメーリングリストを購読します。
やり方は、開発のコミュニティのページに書いてあります。
git send-email を使えるようにする
これについては、前回、git send-email でまとめておきました。
投稿用のパッチを作る
パッチの作り方は、コミュニティのページに説明があると思います。
ログの入れ方とか、いろいろと取り決めがあるので、じっくり読みます。
Linux Kernel を始め、いくつかのコミュニティでは sign-off という制度があります。
sign-off とは、このパッチはオープンソースとして提供しても大丈夫なものですよ、ということを私が証明します、という意味だと、自分なりに理解しています。
自分が一から書いたパッチであれば当然問題はないです。
パッチの中に、別の GPL のコードを含んでいても問題はないです。
一方、GPL とは相容れないライセンスのコードを含んでいたら、NGです。
コミット時に
$ git commit -sのようにすれば、ログに
Signed-off-by: ～ という行が追加されます。パッチ生成時に
$ git format-patch -sのようにしてもいいですが、忘れないように commit 時にやっておくのがいいように思います。
パッチ送る
前回 はとりあえず練習で自分宛に送りましたが、いよいよ今度は本物のメーリングリストに送ります。
初めてパッチを送信する時は、結構ドキドキするものです。
毎回送信先のアドレスを聞いてこないように
$ git config sendemail.to mailing-listの設定をします。プロジェクトごとに送信先が違うはずなので、
--global オプションは付けません。そうすると、この設定はリポジトリごとの .git/config に書き込まれます。git send-email で送ります。初回の投稿の場合、
Message-ID to be used as In-Reply-To for the first email?については、そのまま [Return] でよいです。
自分のパッチが受け付けられたことを確認する
送信するのが初めての場合、すぐにメーリングリストに配信されずに
Your message to <...> awaits moderator approval
みたいな返信が来ることがあります。
一瞬、なんじゃこりゃ？みたいに思うかもしれませんが、心配いりません。
たぶん、スパム対策のために、初めて投稿してくる人に対しては、まともな内容かどうか審査があるんだと思います。
問題なければ、数時間後にはメーリングリストに配信されてくると思います。
2回目からは、すぐにメーリングリストに配信されると思います。
パッチのステータス管理に Patchwork http://patchwork.ozlabs.org/ というシステムを使っているプロジェクトもあります。
自分のパッチもステータス New として登録されていることを確認します。
レビューに対し、返答する
自分のパッチに対し、フィードバックしてくれる人があるかもしれません。
これに対しては、
git send-email ではなくて、普段使っているメーラーで、ごく普通に返信します。修正版のパッチを再投稿する
投稿したパッチがそのまま Accepted になれば万々歳です。
Rejected になれば、基本的にはそこで終わりです。
Changes Requested になった場合は、指摘された部分を修正することで、Accepted になる可能性が高いです。
この場合、元のスレッドに対して修正版のパッチを返信するのではありません。
(Changes Requested になれば、そのスレッドは基本的に終わりです。)
新しいパッチファイルを作り直し、投稿します。
修正をしたら、
$ git commit --amendでコミットを作り直します。
そして、今度はVersion 2のパッチであることがわかるようにタイトルに入れます。
以下のようにすれば git がやってくれます。
$ git format-patch --subject-prefix="PATCH v2" HEAD^さらに、前回のパッチからどこが変わったのかをパッチの中に書き込みます。
$ nano 0001-blabla-blablablaSigned-off-by: ～ の直後に---という行があって、この直後にコメントを入れることができます。
これは git のコミットログには反映されません。
例えば、以下のような感じです。
Signed-off-by: Masahiro Yamada <abc@xyz.com>
---
Changes for v2:
- Fix hogehoge
git send-email で送りますが、今度はMessage-ID to be used as In-Reply-To for the first email?のところに、前回のバージョンのパッチの Message-ID（前回のメールのヘッダを見れば書いてある）を入力します。
これによって、スレッドで関連付けられます。
2013年6月3日月曜日
git send-email
git には send-email というメールを送信するコマンドがあります。
ただし、普通のメールを送信するのに使うというより、パッチを送る用途に使います。
パッチを自分のメーラーに貼りつけて送信してもいいのですが、
メーラーによっては、長い行を勝手に改行してくれたりして、パッチが破壊される可能性もあります。
リポジトリ管理に git を使っているプロジェクトだと、
とするのが手順的にも楽です。
オープンソースの開発にコントリビュートするのに必須ですね。
セットアップについてメモ。
git-core を入れただけでは、
Ubuntu の場合は
でインストールできます。
(他のディストリビューション未確認)
まずは練習のために、自分宛に、何か送ってみましょう。
なんでもいいので、git リポジトリでパッチを生成します。
というのは、メールの送信元 (From: フィールド) のことです。
基本的にコミットログからとってくれるので、それでよければそのまま [Return] を押します。
は送り先です。
今は練習なので、自分のメールアドレスを入れます。
は、今から送るメールが、何か別のメールに対する返信であるときに、引用元の Message-ID を入れておくと、メーラーなどがスレッドの分類などに使ってくれます。
今は、新規メールですので、そのまま [Return] でよいです。
最後に
と聞いてきますので、 間違いがないか確認して、
とします。
ローカルで sendmail 系のサービスが動いていれば、これで送信できちゃいます。
自分は postfix を入れています。postfix の設定は以前、git push でメールをとばす で簡単にまとめた。
postfix など入れてないケースが多いでしょうが、その場合は SMTPサーバーを指定しないといけません。
で設定します。必要であれば
でポート番号を設定します。
プロジェクトごとに別の SMTP サーバーを使う必要は普通はないので、
特に Gmail を使って送信する方法もメモっておきます。
GitTips に書いてありました。
この場合の注意点は、git send-email での表示と無関係に、メールの From フィールドを
ただし、普通のメールを送信するのに使うというより、パッチを送る用途に使います。
パッチを自分のメーラーに貼りつけて送信してもいいのですが、
メーラーによっては、長い行を勝手に改行してくれたりして、パッチが破壊される可能性もあります。
リポジトリ管理に git を使っているプロジェクトだと、
git format-pach でパッチ生成 ⇒ git send-email で送信とするのが手順的にも楽です。
オープンソースの開発にコントリビュートするのに必須ですね。
セットアップについてメモ。
git-core を入れただけでは、
git send-email コマンドはまだ入っていないかもしれません。Ubuntu の場合は
# apt-get install git-emailでインストールできます。
(他のディストリビューション未確認)
まずは練習のために、自分宛に、何か送ってみましょう。
なんでもいいので、git リポジトリでパッチを生成します。
$ git format-patch HEAD^
0001-blabla-blablabla.patch
$ git send-email 0001-blabla-blablabla.patch
0001-blabla-blablabla.patch
Who should the emails appear to be from? [Masahiro Yamada <abc@xyz.com>]
Emails will be sent from: Masahiro Yamada <abc@xyz.com>
Who should the emails be sent to? abc@xyz.com
Message-ID to be used as In-Reply-To for the first email?
Who should the emails appear to be from?というのは、メールの送信元 (From: フィールド) のことです。
基本的にコミットログからとってくれるので、それでよければそのまま [Return] を押します。
Who should the emails be sent to?は送り先です。
今は練習なので、自分のメールアドレスを入れます。
Message-ID to be used as In-Reply-To for the first email?は、今から送るメールが、何か別のメールに対する返信であるときに、引用元の Message-ID を入れておくと、メーラーなどがスレッドの分類などに使ってくれます。
今は、新規メールですので、そのまま [Return] でよいです。
最後に
Send this email? ([y]es|[n]o|[q]uit|[a]ll): yと聞いてきますので、 間違いがないか確認して、
y[Return]とします。
ローカルで sendmail 系のサービスが動いていれば、これで送信できちゃいます。
自分は postfix を入れています。postfix の設定は以前、git push でメールをとばす で簡単にまとめた。
postfix など入れてないケースが多いでしょうが、その場合は SMTPサーバーを指定しないといけません。
$ git config --global sendemail.smtpserver server_addressで設定します。必要であれば
$ git config --global smtpserverport port_numberでポート番号を設定します。
プロジェクトごとに別の SMTP サーバーを使う必要は普通はないので、
--global オプションを付けます。すると、この設定は ~/.gitconfig に書き込まれます。特に Gmail を使って送信する方法もメモっておきます。
GitTips に書いてありました。
~/.gitconfig/に以下を追加
[sendemail]
smtpencryption = tls
smtpserver = smtp.gmail.com
smtpuser = your_account@gmail.com
smtpserverport = 587
git send-email を実行すると Password を聞いてくるので、Gmail のパスワードを入力すると送信できる。この場合の注意点は、git send-email での表示と無関係に、メールの From フィールドを
smtpuser = your_account@gmail.com で指定したアドレスに強制的に置き換えてしまうことです。
登録:
投稿 (Atom)