User Tools

Site Tools


ja:submitting-patches

パッチの提出

パッチは、Github での Pull Request として、またはメーリングリストで提出することができます。

提出の際、以下のガイドラインに従います:

  • Pull Request 毎に異なるブランチを使用すること(GitHub は、Webサイトを通してファイルを編集した場合これを自動的に行います)
  • コミットの subject およびメッセージは、命令形で書くこと: “added support for X” ではなく “add support for X”
  • コードの書式
    • 編集したファイル内にあるインデントと同じ余白を使用すること。ファイル内の他の個所で使用されているものに従ってタブのみ、またはスペースのみを使用する。
    • リストの項目はアルファベット順に配置すること
  • コミットの subject
    • あなたが何に関してコミットしようとしているかに従って、プレフィクスを持つこと
      • kernel: カーネル及び kmod (kernel module) パッケージ向け
      • パッケージ名: パッケージ向け
      • デバイス アーキテクチャ: デバイス向け (例えば、mvebu:ramips: add support to example_eval board
      • ツール名: ツール向け
      • build: /toolchain の何らかを対象としたものではない、一般的なビルドシステムの変更向け
    • 50文字未満であること
    • プレフィクスの後の最初の単語は大文字にしないこと
    • subject 行の最後に終止符を書かないこと
  • コミットの description
    • 1行あたり75文字未満であること
    • コミットの変更が何であり何故必要なのかを説明すること
      It is challenging to be both succinct and descriptive, but that is what a well-written summary should do
    • it will be committed to the source changelog, so it should explain to a competent reader why you made this commit.
      Include symptoms of the failure you are fixing (log messages, error messages, etc.), it will be useful for
      people searching the commit logs looking for a fix for their issue.
      If a patch fixes a compile failure, include only the most relevant part of the failure log
    • 新規ハードウェアのサポートを追加する場合: コミットメッセージにハードウェアの短い説明と LEDE のインストール方法を含めること。いくつかの例として、最近の追加 を見てください。
  • 全てのコミットは、あなたの本名と所有するメールアドレスを記した Signed-off-by: My Name <my@email.address> を含むこと。これは Section 11 of the Linux Kernel patches guide に該当します。
    • これは次の git コマンドラインにより自動的に行われます:
      git commit --signoff
  • Auther フィールドが “Signed-off-by:” 行と一致すること
    • もしあなたがGitHubを通してファイルを編集している場合、GitHub の設定の “Name” 欄にあなたの本名を書かなければなりません。また、“Signed-off-by:” に使用されているメールアドレスが GitHub の優先的なメールアドレスでなければなりません。
    • もしあなたがローカルのPCでファイルの編集とコミットを行っている場合、次の通りに名前とメールアドレスを設定します:
      git config --global user.name "my name"
      git config --global user.email "my@email.address"

Github での作業

ソースリポジトリの Github ミラーがここにあります。
Github web インターフェースを用いてプロジェクトを公開リポジトリにフォークし、あなたのコンピュータに clone して、変更のためのブランチを作成し、それらを Github へ push して Pull Request を提出します。

このやり方について知らない場合、そのまま読み進めてください。

Github アカウントを作成します。これは LEDE ソースの公開フォークのホストと、Github での全ての活動に使用されます。

git をあなたのPCにインストールし、本名とメールアドレスを持つローカルの git 設定を作成します

git config --global user.name "my name"
git config --global user.email "my@email.address"

あなたはデフォルトのテキストエディタをお気に入りのエディタに設定したいかもしれません。 もし GUI の Linux システムを持っている場合、選択肢の一例はgeany, kwrite, pluma, geditです。
もしコマンドラインを使用している場合、nano が良いエディタでしょう。

git config --global core.editor "editor-name-here"

この時、Github のドキュメント Fork A RepoCreate a local clone of your fork も参考にします

説明通りにそれらを設定後、PR (Pull Request) のために

git checkout -b my-new-branch-name

とコマンドを入力して、新規ブランチを作成します(“my-new-branch-name” は例であり、あなたにとってよりわかりやすい名前を使用します)。
このコマンドより後にあなたが行った全コミットは、このブランチにまとめられます。複数のブランチを持つこともでき、PR 毎に1つを使用します。
作成済みのブランチ間を切り替えるには、

git checkout my-branch-name

を使用します

変更を作成後、

git add -i

と入力し、そのインターフェースを使用して untracked(新規)ファイルと既存ファイルの変更を追加します。

その後、以下を実行します

git commit --signoff

これは git のデフォルトエディタを開き、あなたはコミットメッセージを書くことができます。
最初の行にコミット subject を、
1行空けて
コミット description(説明)を記入します。
このコマンドは、上記で設定したあなたの名前とメールアドレスを含む Signed-off-by 行を自動で追加します。
例として、以下のような完全なコミットメッセージです:

The best code update.

This is the best piece of code I have ever submitted.
Signed-off-by: John Doe <John.Doe@test.com>

ローカルでの変更を Github 上に送るには、次を入力します

git push --all

このプロセスでは、Github のユーザー名とパスワードが尋ねられるでしょう。

Github リポジトリへコードがアップロードされた後は、Github Web インターフェースを使用して PR を提出することができます。再度 Creating a pull request についての Github のドキュメントを参照してください

メールによるパッチの提出

メールを development mailing list に送信します。全てのパッチは patchwork に掲載されているものと同じフォーマットで送信される必要があります。もしパッチが patchwork に掲載されない場合、そのパッチについては対応が行われません。 git send-email の使用を特に推奨します。電子メールクライアントはスペースの付加やフォーマットの改変、または印刷が不可能な文字の付加を行う傾向にあるためです。

コミットの取り纏め

PR 内またはメールにより送信されるコミットはあなたがマージしてほしい全ての変更についてのものであるべきで、レビュアーが元の PR から見つけた問題の修正についてではありません。

そのため、あなたがコミットを書き直すか取りまとめる必要のある時が来るでしょう; so you end with a normal amount of true and sane commits.

git コマンドラインで作業します。
開発フォルダに移動します。
既存のブランチを確認します:

git branch -a

次のような結果が表示されます:

  best_code_update
* master

この PR の開発ブランチに切り替えます:

git checkout best_code_update

git logを確認し、取り纏めたいコミットの数(“X” とする)を次のコマンドにより数えることができます:

git log

コミットを削除します:

git reset HEAD~X

(X は削除したいコミットの個数であり、最新のコミットから数えます)これは編集済みのファイルは変更せず、コミットのみ削除します。
ファイルを再度 git tracking に追加します:

git add -i

そして再度コミットします:

git commit --signoff

更新したブランチを Github 上に送信します:

git push -f

この際、“-f” オプションを付加して強制的に push する必要があります。
すると、PR のコミットは自動的に更新されます。

代替的な取り纏めのアドバイス:

まとめるために interactive rebase を使用できます。コミットとコミットメッセージの整理、編集を行います:

git rebase -i HEAD~X

(X = 編集するコミットの番号)

パッチのマージおよびツリーのライフサイクル

We encourage frequent committers to host their own staging trees where they aggregate patches that they feel responsible for and/or ones that they created themselves. Once the tree has been reviewed and tested it can be proposed for inclusion in the master branch.

  1. ツリーはいかなる時も master へマージされます
  2. バグ修正は master へ直接マージされることが可能です
  3. PRs can be sent to the patches mailing list from any source and will always be considered for inclusion if the quality of the tree is good and format of submission is correct
  4. Staging trees can be hosted as part of the projects git infrastructure, private servers, GitHub …

パッチ チェックリスト

  1. 単一のコミット ( 複数のコミットは、上記で説明した通り最初に取り纏めなければなりません。)
  2. Subject < 50文字
  3. subject の次の行が空白
  4. description の各行 < 75文字
  5. description で何が変更されたのか説明している
  6. Description で何故それが変更されたのか説明している
  7. Description makes sense
  8. Signoff 行が本名を含んでいる
  9. Signoff 行が所有するメールアドレスを含んでいる
ja/submitting-patches.txt · Last modified: 2018/03/01 08:54 by tmomas