そこの君、バグ報告から始める

Mozillaへのcontributeのやり方教えてあげるからちょっと来なさい

saneyuki_s

About Me

• saneyuki_s• とんかつ好き• 動いてる場所• Firefoxのフロントエンド• ドキュメント翻訳• アドオン開発

お品書き

1.バグ報告というOSS contribute

2. Firefoxにおけるバグの修正ステップ

バグの報告丁寧にできてますか？

バッドパターン

なぜbadなのか？

なぜbadなのか

•前提となる状況（環境）がわからない•再現手順がわからない•「どうしてほしいのか？」が不明瞭

必要な情報

•再現環境（絞り込めた方がよい）•再現手順（絞り込めた方がよい）•本来望まれる結果（具体的に）

必要な情報（Firefoxの場合）• 再現環境• OS, CPUアーキテクチャ、ビルド元• アドオンも最小限度に。セーフモードで絞り込む• 再現手順• 適度な粒度で最小限に• 本来望まれる結果• 具体的にはっきりと。

Firefox/Thunderbird で参照すべきは

about:support必要な情報が詰まっている

about:support

•変更された本体設定•インストールされてるアドオン•本体バージョン•HWAの動作の有無•ビルド元revision→about:buildconfig

Mozillaのバグ修正篇

Mozilla製品のバグの報告先

• bugzilla.mozilla.org•通称BMOないし「bugzilla」• Github etc...• 新規実験プロジェクトは殆どこっち•（実装者本人）

STEP 1バグを登録する

バグを登録する

•基本は今まで説明した通りで大丈夫•関係してそうな人をCCに突っ込む•テストケースを追加すると尚良い

STEP 2パッチを書く

パッチを書く

•参照すべきドキュメント:たくさんある• https://developer.mozilla.org/en-US/docs/Developer_Guide

•詰まったらfeedbackを誰かに依頼する•コードとにらめっこが基本•テストケースの追加も必要

パッチをレビューしてもらう

レビューしてもらう•最大の難所• レビュアーがわからない場合は探す• https://wiki.mozilla.org/Modules• レビュー以来して放置プレイよくある• コードバトルっぽいやりとりになる• 諦めずに説明するのが重要

ソースツリーにland

ツリーにland

• BMOなら該当バグにcheckin-neededフラグを付ける

• Githubの場合はpull requestからの自然な流れ

•（自分でland）

バグ修正完了！

1.バグを登録

2.パッチを書く

3.コードレビュー

4.ソースツリーにland

こぼればなし

こぼればなし※個人の感覚であり

実際とは異なる場合があります

voteは意味ない？case 1

*chのFirefoxスレで見かけるレス

「2*hで騒いでないで、直してほしいんだったら

voteしろよ」

bugzillaのvote機能

voteは意味ない？

• voteは目安• そもそもデフォルトでメール通知が来ない• 長期的な修正目標には考慮されるけど「すぐに直してほしい」場合には使えない

•変更に疑問・不満があるのなら、内容が重複していてもコメントすべき

直し易いバグ直し難いバグ

case 2

登録したバグが必ず修正できるとは限らない

• 根拠が例示されているバグは直しやすい•仕様に準拠していない•こうするとセキュリティホール•このケースで落ちる

• 根拠の判断基準が難しいバグは直し難い•こんなUIはおかしい（実装の修正なら簡単）

•デザインがおかしい•UI系は担当者によっては放置プレイ・問答無用のWONTFIXとかフツー

パッチの自動テストcase 3

パッチのレビュー中にしばし言われるコメント

「このパッチ、テストしてある？」

テスト（・ω・）？

提出されたパッチはテストをPASSする必要がある

•テストツールたくさんある•全プラットフォームでテストの必要がある

•正直、個人では難しい規模

じゃあどうする？

•テストをしぼって実行•頑張って全部実行•コミッタに頼んでMozillaのテストサーバを使う←簡単！

個人的に感じた大切なこと

OSSにおいて重要な物

OSSにおいて重要な物コミュニケーション

Any Question?