Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
そこの君、      バグ報告から始めるMozillaへのcontributeのやり方教えてあげるからちょっと来なさい        saneyuki_s
About Me• saneyuki_s• とんかつ好き• 動いてる場所 • Firefoxのフロントエンド • ドキュメント翻訳 • アドオン開発
お品書き1. バグ報告というOSS contribute2. 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     バグ修正完了!
こぼればなし
こぼればなし   ※個人の感覚であり実際とは異なる場合があります
case 1voteは意味ない?
*chのFirefoxスレで見かけるレス「2*hで騒いでないで、直してほしいんだったら   voteしろよ」
bugzillaのvote機能
voteは意味ない?• voteは目安 • そもそもデフォルトでメール通知が来ない • 長期的な修正目標には考慮されるけど  「すぐに直してほしい」場合には使えない• 変更に疑問・不満があるのなら、 内容が重複していてもコメントすべき
case 2直し易いバグ直し難いバグ
登録したバグが必ず修正できるとは限らない
• 根拠が例示されているバグは直しやすい • 仕様に準拠していない • こうするとセキュリティホール • このケースで落ちる
• 根拠の判断基準が難しいバグは直し難い • こんなUIはおかしい  (実装の修正なら簡単) • デザインがおかしい • UI系は担当者によっては放置プレ  イ・問答無用のWONTFIXとかフツー
case 3パッチの自動テスト
パッチのレビュー中に    しばし言われるコメント「このパッチ、テストしてある?」
テスト(・ω・)?
提出されたパッチはテストをPASSする必要がある• テストツールたくさんある• 全プラットフォームでテストの  必要がある• 正直、個人では難しい規模
じゃあどうする?• テストをしぼって実行• 頑張って全部実行• コミッタに頼んで Mozillaのテストサーバを使う←簡単!
個人的に感じた 大切なこと
OSSにおいて重要な物
OSSにおいて重要な物コミュニケーション
Any Question?
Upcoming SlideShare
Loading in …5
×

そこの君、 バグ報告から始める Mozillaへのcontributeのやり方 教えてあげるからちょっと来なさい

3,072 views

Published on

Published in: Technology
  • Login to see the comments

そこの君、 バグ報告から始める Mozillaへのcontributeのやり方 教えてあげるからちょっと来なさい

  1. 1. そこの君、 バグ報告から始めるMozillaへのcontributeのやり方教えてあげるからちょっと来なさい saneyuki_s
  2. 2. About Me• saneyuki_s• とんかつ好き• 動いてる場所 • Firefoxのフロントエンド • ドキュメント翻訳 • アドオン開発
  3. 3. お品書き1. バグ報告というOSS contribute2. Firefoxにおけるバグの修正ステップ
  4. 4. バグの報告丁寧にできてますか?
  5. 5. バッドパターン
  6. 6. なぜbadなのか?
  7. 7. なぜbadなのか• 前提となる状況(環境)がわからない• 再現手順がわからない• 「どうしてほしいのか?」が不明瞭
  8. 8. 必要な情報• 再現環境(絞り込めた方がよい)• 再現手順(絞り込めた方がよい)• 本来望まれる結果(具体的に)
  9. 9. 必要な情報(Firefoxの場合)• 再現環境 • OS, CPUアーキテクチャ、ビルド元 • アドオンも最小限度に。セーフモードで絞り込む• 再現手順 • 適度な粒度で最小限に• 本来望まれる結果 • 具体的にはっきりと。
  10. 10. Firefox/Thunderbird で参照すべきはabout:support 必要な情報が詰まっている
  11. 11. about:support• 変更された本体設定• インストールされてるアドオン• 本体バージョン• HWAの動作の有無• ビルド元revision→about:buildconfig
  12. 12. Mozillaのバグ修正篇
  13. 13. Mozilla製品の バグの報告先• bugzilla.mozilla.org • 通称BMOないし「bugzilla」• Github etc... • 新規実験プロジェクトは殆どこっち• (実装者本人)
  14. 14. STEP 1バグを登録する
  15. 15. バグを登録する• 基本は今まで説明した通りで大丈夫• 関係してそうな人をCCに突っ込む• テストケースを追加すると尚良い
  16. 16. STEP 2パッチを書く
  17. 17. パッチを書く• 参照すべきドキュメント:たくさんある • https://developer.mozilla.org/en-US/docs/Developer_Guide• 詰まったらfeedbackを誰かに依頼する• コードとにらめっこが基本• テストケースの追加も必要
  18. 18. パッチをレビューしてもらう
  19. 19. レビューしてもらう• 最大の難所• レビュアーがわからない場合は探す• https://wiki.mozilla.org/Modules• レビュー以来して放置プレイよくある• コードバトルっぽいやりとりになる• 諦めずに説明するのが重要
  20. 20. ソースツリーにland
  21. 21. ツリーにland• BMOなら該当バグに checkin-neededフラグを付ける• Githubの場合は pull requestからの自然な流れ• (自分でland)
  22. 22. 1. バグを登録2. パッチを書く3. コードレビュー4. ソースツリーにland バグ修正完了!
  23. 23. こぼればなし
  24. 24. こぼればなし ※個人の感覚であり実際とは異なる場合があります
  25. 25. case 1voteは意味ない?
  26. 26. *chのFirefoxスレで見かけるレス「2*hで騒いでないで、直してほしいんだったら voteしろよ」
  27. 27. bugzillaのvote機能
  28. 28. voteは意味ない?• voteは目安 • そもそもデフォルトでメール通知が来ない • 長期的な修正目標には考慮されるけど 「すぐに直してほしい」場合には使えない• 変更に疑問・不満があるのなら、 内容が重複していてもコメントすべき
  29. 29. case 2直し易いバグ直し難いバグ
  30. 30. 登録したバグが必ず修正できるとは限らない
  31. 31. • 根拠が例示されているバグは直しやすい • 仕様に準拠していない • こうするとセキュリティホール • このケースで落ちる
  32. 32. • 根拠の判断基準が難しいバグは直し難い • こんなUIはおかしい (実装の修正なら簡単) • デザインがおかしい • UI系は担当者によっては放置プレ イ・問答無用のWONTFIXとかフツー
  33. 33. case 3パッチの自動テスト
  34. 34. パッチのレビュー中に しばし言われるコメント「このパッチ、テストしてある?」
  35. 35. テスト(・ω・)?
  36. 36. 提出されたパッチはテストをPASSする必要がある• テストツールたくさんある• 全プラットフォームでテストの 必要がある• 正直、個人では難しい規模
  37. 37. じゃあどうする?• テストをしぼって実行• 頑張って全部実行• コミッタに頼んで Mozillaのテストサーバを使う←簡単!
  38. 38. 個人的に感じた 大切なこと
  39. 39. OSSにおいて重要な物
  40. 40. OSSにおいて重要な物コミュニケーション
  41. 41. Any Question?

×