パッチを投稿してみた話
TRANSCRIPT
パッチを投稿してみた話wata2ki
自己紹介
名前 : wata2ki (watatuki) ◦ 元はハードウェアで画像処理をやっていましたが、現在
は組み込み屋をやっています
◦ 最近は Jetson-TK1 の Upstream BSP を作って、それをベースに Automotive Grade Linux の移植をしています ( 非公式 のはず｡｡ )
◦ 次は、 R-Car M3TX1 だ！ やっとベースの wayland 環境がビルドできました
◦ GitHub https://github.com/watatuki
概要
前回の勉強会で、パッチの投稿のしかたがわからないという話があったので、 github でどんな操作をしてパッチを投稿するのかを説明します
とあるオープンソースプロジェクトでパッチを投稿した時のレビューの経験も反映しています
OSS プロジェクトにもいろいろある 明確にルールが決まっている所は、それに従う必要がある
◦ この例では、パッチは git を使ってメーリングリストに投稿するか、 github で fork して pull リクエストを送るように書かれている
といっても、 github ではルールが明記されていないことが多い
UpstreamingMailing ListSend pull requests to [email protected] with '[meta-musl]' in the subject'When sending single patches, please use something like
git send-email -M -1 --to [email protected] --subject-prefix=meta-musl][PATCH
Forking via githubYou are encouraged to fork the mirror on github to share your patches, this is preferred for patch sets consisting of more than one patch. Other services like gitorious, repo.or.cz or self hosted setups are of course accepted as well, 'git fetch ' works the same on all of them. We recommend github because it is free, easy to use, has been proven to be reliable and has a really good web GUI.
何に気を付ければよいか Github のプロジェクトの場合、通常は github の仕組み
を使ってパッチを投稿する ( プルリクエストを送る )◦ README に何も書かれていない場合は基本この方法
投稿するパッチの内容は気にしなくてよい◦ そのパッチで追加される機能の良し悪しはメンテナが判断するので、
自分が価値があると思えば投稿してよい
パッチを送る場合はコミットログやプルリクエストのメッセージに注意◦ コミットログやプルリクエストのメッセージに内容をきちんと書か
ないと、そのパッチが何のパッチなのかをコードで判断しなければならず、メンテナが中身を見ずにリジェクトしてしまう場合がある
Github でパッチを送る方法 -fork- Github のパッチ投稿は fork で始まる 貢献したいプロジェクトのリポジトリに行って 1 クリックで
終わり
ポチ
Github でパッチを送る方法 –ブランチ作成 - Fork したら、最初にブランチを作成する
◦ ブランチを作らなくてもコミット～プルリクエストは可能だが、あとで恥ずかしいコミットを直すためのブランチ再作成ができなくなる
ブランチ名を入れる
ポチ
Git push した後にamend で修正したせいでできた変なマージコミット
コミットログを適当に入れて、そのまま push しちゃったログ
Github でパッチを送る方法 –コミット - コミットログはきちっと書こう
xf86drmMode.h: Add DisplayPort MST and DPI encoders/connectors
This brings xf86drmMode.h in sync with include/drm/drm_mode.h.Eventually we really should only have a single set of definitions rather than duplicating this in two files.
v2: add DPI encoder and connector types introduced in Linux v4.7
Reviewed-by: Emil Velikov <[email protected]>Signed-off-by: Thierry Reding <[email protected]>
1 行目はパッチファイルのタイトル &mbx 形式のsubject になるので、終端にピリオドをつけてはいけない。また空行を後ろにつけないといけない。
3 行目からは、そのパッチが何を目的としてなぜ必要なのかを書く。有名どころは、 Signed-off( コミッターの署名 ) が必要。
ただ、 github のリポジトリは適当なものが多いので、 Signed-off が何を示すかを提示していないことが多い。何も書かれていなければ不要。必要な場合は、 git commit –signoffを使うことで署名できる、名前とメールアドレスの設定も忘れずにgit config --global user.name "Firstname Lastname“git config --global user.email "[email protected]"
Github でパッチを送る方法 –プルリクエスト - Commit/push して github にパッチを登録したら、今度はプルリク
エストを使ってマージを依頼する◦ Github では、プルリクエストのメッセージはコミットログ以上に重要なのでき
ちんと書こう
ポチ
ポチ
タイトルと説明文 ( 挨拶みたいなものも多い ) を書く
Github でパッチを送る方法 –プルリクエスト - 誰かがプルリクエストを
送ってくれると、 github から通知が来る◦ 自分のリポジトリの pull
requests にプルリクエストの内容が表示されるので、マージする / 返信する
github 以外の場合
Github 以外のプロジェクトの投稿方法◦ コミットログの注意点は同じ
プルリクエストメッセージがなくコミットログだけになるので、より重要になる
◦ 投稿の方式 メーリングリストに投稿
実際にやったことはないですが、 git send-email を使って投稿できるようです
Gerrit を使ったレビュー git push のかわりに git review で投稿できるようになっている
（はず） レビューの内容は、プロジェクトの gerrit で確認して、修正が
必要であれば、 git commit -–amend で修正した後、再度 git review する
まとめ
今回は、 Github でパッチを投稿する流れを説明しました
実際やってみるといろいろなことが起きますが、◦ はずかしいスペルミス修正コミットの山とか・・◦ 変なマージコミットとか・・・◦ 英語コワイ
コミットログと修正履歴をしっかり見る人なんてそんなにいないので気にしない！
まずは、やってみましょう◦ リジェクトされても自分のフォークは残るので、自分の成果がな
くなるわけではないです