Site /

\ Site

コードに貢献

https://www.chromium.org/developers/contributing-code

すでにチェックアウトしビルド済みであること。ChromiumはChromiumOSにもプルされる。

会話

新しい機能を追加するにしても、バグを直すにしても、やりすぎる前に他の人の意見を聞くように。新しいアイデアなら、適当な議論グループ(Chromium | ChromiumOS）で提案。既存コードなら"OWNERS"ファイルに乗ってる人に聞く。（コードレビューを参照）。
動作変更や些細でない修正はbug systemで追跡される必要がある。バグを提出してあなたが何をやっているのかを示す。
bug systemにバグが乗っているからといってパッチが受け入れられるとは限らない。

法的関連

Individual Contributor License Agreementを成就すること。オンラインでできる。企業として貢献するならCorporate Contributor License Agreementを記入して送る。
初めてコードを送る場合は、AUTHORSファイルに名前（企業の場合は企業名）と連絡先を書き入れる。
レビューはExternal Contributor Checklistに従う。

ローカルブランチを作成

ブランチをきることから作業が始まる。以下はmychange（名前は任意）というブランチをつくり、上流レポジトリのorigin/masterブランチを追跡する。

git checkout -b mychange -t origin/master

ここでコードを書いたりテストをする。

スタイルガイドに従うこと。
適切なユニットテストを含めること。
パッチはレビューしやすいサイズに収めること。大きいパッチのレビューには時間がかかる。quickly.

ローカルにコミット

git commit -a

変更をレビューのためにアップロード

gitの初期設定

https://chromium-review.googlesource.com/new-passwordからアップロードのための信任状を得て画面の支持に従う。

名前やメールアドレスやその他の設定

git config --global user.name "My Name"
git config --global user.email "myemail@chromium.org"
git config --global core.autocrlf false
git config --global core.filemode false
git config --global branch.autosetuprebase always
git config --local gerrit.host true

アップロードコマンド

レビューにはhttps://chromium-review.googlesource.comで動いているGerritを使っている。変更をGerritにアップロードするには、git-clツールを使う。このツールはdepot_toolsに入っている。

git cl upload

このコマンドはGerrit変更を作成する。書き込みの入力が促され、送信前に簡単なエラーチェックが行われる。それが終わったら、URLを出力する。WEBで変更を見るために使う。

コマンドラインオプションでCLに対するレビューアとこの変更で修正したバグを指定することができる。

git cl upload -r foo@example.com,bar@example.com -b 123456

コード品質のガイドライン

ベストなコードにするために、メンテナンスの容易性は重要である：

基本原則に従う。
コードは読みやすく書かれていること。
プラットフォームに依存しないためのコードやより良いデザインのためのリファクタリングを躊躇しないこと。
近道をしないこと。開発は１００ｍ走ではなくマラソン。
始めてみたときよりもきれいなコードにすること。

コミットの書き込み

以下の形式で書く。

Summary of change

Longer description of change addressing as appropriate: why the change is made,
context if it is part of many changes, description of previous behavior and
newly introduced differences, etc.

Long lines should be wrapped to 80 columns for easier log message viewing in
terminals.

Bug: 123456

短いサブジェクトと１行のブランクラインは必須。問題トラッカーからのバグ番号を使う（バグフォーマット参照）。以前のCLのリンクを含めるなら、chromium-review.googlesource.com/c/NUMBERではなくcrrev.com/c/NUMBERを使うことを考慮。crrev.comのほうが短いし、CLが提出されたときの混乱を回避できる。提出されたCLにはコードレビューページへのリンクをもち、参照CLにはcrrev.comを使うと間違ったリンクをクリックせずに済む。

良いgitコミットメッセージの書き方はここ。

テスターに対して変更が正しいことを検証するやり方がある場合には以下を追加：

@@ Test: Load example.com/page.html and click the foo-button; see crbug.com/123456 for more details. @@

コードレビュー

より詳細はコードレビューポリシーページを参照。

レビューアを見つける

理想的にはレビューアは変更したコード近辺に親しい人がよい。わからなければgit blameでファイルやOWNERSファイルを調べる。

誰もがコードレビューできるが、最低１人は変更したコードのディレクトリのオーナーでなければならない。
複数のレビューアがいる場合は、各々のレビューアに何を期待しているかを明確にしてレビューの要求をすること。そうしないとその人達は自分の入力が必要ないとみなすか、冗長なレビューをしてしまう。
git cl ownersコマンドでオーナーを見つける手助けができる。

レビューの要求

変更をウェブで開く（リンクが見つけられない場合は、git cl issueを実行して現在のブランチのissueをみるか、chromium-review.googlesource.comへ行って、ログインして、Outgoing Reviewsを見る。

レビューアはコードがコンパイルできてテストにパスしていることを期待している。アクセスできるなら、このときに変更の自動テスト（下記参照）を実行するとよい。

左上のAdd Reviwersをクリックして（リンクが見えないなら、ログインする）、Reviwersフィールドで、選んだレビューアをコンマで区切って入力する。

同じダイアログで、レビューアへの最初のメッセージをタイプしてSendをクリック。これでレビューアにメールが送られレビュー要求があることを知る。レビューに疑問点ややり方がある場合は、メッセージボックスに入力する。しかし空白のままでもよい。

レビュープロセス

すべての変更はレビューされなければならない。コードレビューポリシーを見ること。

新しいパッチセットをアップロードするには、単に変更をローカルブランチにコミットして再びgit cl uploadを実行する。

承認

レビューアがパッチに満足したら、彼らは"Code-Review +1"をセットする。

コミットするには影響するすべてのファイルのオーナーから承認を得る必要がある。コードレビューポリシーのオーナーセクションを参照。

自動テストの実行

提出される前に、変更は大きい一連のコンパイルと多くのプラットフォームにまたがったテストにパスしなければならない。このプロセスを開始するには、コードレビューツール右上のCQ dry run（CQ = コミットキュー）を押す。これは"Commit-Queue +1"を同等である。このラベルは誰にも利用可能だが、CQはコードが安全でないと判断すると、テストを実行しない可能性もある。安全とみなされるには：

@chromium.orgのメールアドレスを持っているなら、自分でトライジョブをリクエストする。
いくつかのパッチをつくったのなら、レビューアに自分をトライジョブにノミネートしることをリクエストする。
それ以外の場合、コードレビュ要求メッセージ内に、これがはじめてのパッチでトライジョブを実行してほしいことをリクエストする。

コミッティング

変更は一般的にはコミットキュー経由でコミットされるべきである。これは右上のSubmit to CQボタンをクリックすることで行われか、変更に"Commit-Queue +2"ラベルを設定することで行われる。そうするとコミットキューはパッチをトライボットに送る、そうするとコードレビューツールの内のチェックボックスの近くに色のついた泡が現れる（ドライランでも同じ）。すべてのテストがパスしたら、変更は自動コミットされる。失敗したら、赤い（失敗）泡の失敗リンクをクリックする。ときどきテストはflakyになる。変更と関係ない孤立した失敗だったら、少し待ってまたcommitをクリックする。

他の方法として、コミットキューをスルーして変更を直接コミットすることも可能である。これはテストをスルーするので緊急時のみに使うべきである。

チップ

レビューの期間、マージの苦労を最小にするため、自分の変更を新規ソースリビジョンにリベースしたいかもしれない。レビューアに優しい方法はリベース（リベース以外の変更がない）それ自信をパッチセットとしてアップロードすることである（when there are no outstanding comments.）その後、変更のパッチをアップロードする。この方法によりレビューアはリベースとは独立して変更を見ることができる。

コードの書き手とレビューアはChromiumはグローバルなプロジェクトであると常に心すること。貢献者とレビューアはしばしばタイムゾーンが大きく離れている。レビューラグを最小にするガイドラインを読んで、レビューを書くときもそれに応答するときもそれを考慮すること。

Edit | History | Recent Changes (all) | Search

Page last modified on July 21, 2018, at 09:22 AM