OSSやってみる～OpenJDKの場合～（Java女子部 OSS開発はじめのいっぽ勉強会講演資料）

© 2020 NTT DATA Corporation 1 © 2020 NTT DATA Corporation
OSSやってみる
～OpenJDKの場合～
2020年02月16日
株式会社NTTデータ末永恭正
#javajo

© 2020 NTT DATA Corporation 2 #javajo
OSS、使ってますか？

使うからこそ思うこと
• こうだったらもっと使いやすいのに
• この部分、こう書きかえればもっとよく動くんじゃ？
• ここの動き、ヘンじゃね？
• このマニュアルわかりにくい

OSSやってみる
チャンス！！！

いろいろな貢献
• 疑問をぶつける
• 新機能の提案をする
• バグ報告をする
自作のプログラムを公開する／パッチを出すだけがOSS活動ではない！
何か言ってみるパッチ出してみる

ドキュメント修正だって立派な貢献！
• 使いたい／作りたい人の基本となるもの
• ユーザー／開発者獲得の大きなポイント
• 開発に携わっていないからこそ気づくことだってある
Windows Terminalの場合：

「思ったこと」が大きな結果に繋がることも
• 自分が思ったことは他の人も思っているかもしれない
• 単に声を上げていないだけかもしれない
• 開発者にとって外部からの声は気づきの宝庫！
• 開発者は見えすぎていて、”わからないこと”が”わからない”

そうは言っても
いろいろ不安が…

腕に自信がない…
• 根拠に基づく話をすればいい
• コミッタだって人間→間違える
• 根拠：オフィシャルドキュメントとか
• パッチの場合、レビューで指摘されたことを
しっかり納得して反映していけばいい
• いろいろ教えてもらえるいいチャンス！

英語つらい…
• 便利サイトに頼ってみる
• 英辞郎： https://www.alc.co.jp/
• Google翻訳： https://translate.google.co.jp/
• 外国の開発者は理解しようとしてくれる
• 困ったらコードを引用すればいい
• テキストベースのコミュニケーションならイケる！
• 会話じゃないからリアルタイム性は求められない
• コメント文の表現とかはレビュー時に直してくれる！

OSS活動やってみる！
その前に…

必要なことをチェックしておこう
• 報告、提案、議論の出し方
• GitHub Issue、Google Groups、メール、etc…
• 公式リポジトリ
• GitHubがオフィシャルとは限らない
• 同意書の要否
• CLA（Contributor License Agreement）と呼ばれるもの
• 企業発OSSはCLAを求めることが多い（気がする）
• その他、コミュニティの「流儀」
• （GitHubプロジェクトなら）基本的なことはREADME.mdや
CONTRIBUTING.mdに書いてあることも

OSS活動やってみる！
～OpenJDKの場合～

OpenJDK
• https://openjdk.java.net/
• オープンソースなJava実装
• Sun JDK（Oracle買収前）がオープンソースになった
• ライセンスはGPLv2 Classpath Exception
• 様々な会社がOpenJDKのビルドを出している
• Red Hat、Amazon、SAP、etc…
• コミュニティとしてオフィシャルのバイナリは出していない
• 最近のJavaのリファレンス実装的なもの
• Oracle JDKもOpenJDKがベース
• なにかと話題のGraalVMのベースにもなっている

コントリビューター視点でのOpenJDKの特徴
• コード管理がMercurial
• http://hg.openjdk.java.net/
• GitHubはクローン（2020/02現在）
• IssueやPull Requestを現時点では受け付けていない
• GitHubへの移行を検討中ではある
画面左側のリンクから各プロジェクトのリポジトリを参照する

• バグ管理はJIRA
• https://bugs.openjdk.java.net/
• コミュニティでの権限がないと書き込み不可

• 議論がML
• https://mail.openjdk.java.net/
• 出し先を自分で気を付けなければいけない
• 不適切な場合でも、受け取った人が正しいところへ
CCしてくれることがよくある
とにかく数が多い！
（ARCHIVED（新規投稿不可）も残されている）

• コントリビューションには
OCA（Oracle Contributor Agreement）の提出が必要
• 議論するだけなら不要

OpenJDKコミュニティの人たち
Project
Lead
Reviewer
Committer
Author
Contributor
※上位者は下位者の権限を継承する

Contributor
• パッチを出す人
• レビュー資材作成やPushに
Sponsorの協力が必要
Project
Lead
Reviewer
Committer
Author
Contributor
https://openjdk.java.net/bylaws#contributor

Contributorとしてパッチがコミットされると…

Author
• コミットを作れる人
• 以下へのアクセス権を持つ
• バグ管理システム（JBS）
• コードレビューサーバ
• PushはSponsorに依頼
• hg exportコマンド
• 2個以上の「ちゃんとした」
コミットを持つ人がProject
Leadにメールするとなれる
Project
Lead
Reviewer
Committer
Author
Contributor
https://openjdk.java.net/bylaws#author

Committer
• リポジトリにPushできる人
• Sponsorとして支援も可
• Submit Repoの利用権あり
• 8個以上の「ちゃんとした」
コミットを持つ人が投票で
役割を与えられる
• 必ずしも
Authorである必要はない
Project
Lead
Reviewer
Committer
Author
Contributor
https://openjdk.java.net/bylaws#committer

Reviewer
• 修正のレビューをする人
• Reviewerの同意がないと、
超緊急なパッチでも
Pushしてはいけない
• 32個以上の
「ちゃんとした」コミット
を持つCommitterが投票で
役割を与えられる
Project
Lead
Reviewer
Committer
Author
Contributor
https://openjdk.java.net/bylaws#reviewer

Project Lead
Project
Lead
Reviewer
Committer
Author
Contributor
• OpenJDK配下の
開発プロジェクトリーダー
• 開発の方向性や活動に
責任を持つ
• プロジェクト毎に1人
• たまに人が代わる
https://openjdk.java.net/bylaws#project-lead

パッチがマージされるまで

ネタ発見！
JBSに登録
パッチを作る
Submit Repoでテスト
コードレビューサーバへUp
MLでレビュー
コミット
プッシュ
（バックポート）
基本的な流れ
パッチづくり＆改善
（繰り返し）
修正する

JBSに登録
基本的な流れ：問題・改善の登録
• まずはチケット番号を取る
• JDK-xxxxxxxの形式
• Author以上でないと
JBSに書き込めない
• Contributorはここから
Sponsorが必要
• つまり、何か見つけた時点で
MLで議論する必要がある

基本的な流れ：パッチづくりからレビューまで
• パッチを作ったら
Submit RepoへPush
• Committer以上が使える
• パッチを
• webrev形式
• 修正箇所に関連する議論を行う
MLへレビュー依頼を送信
• 最低でもReviewer×1以上の
同意をもらうまでサイクルを繰り返す
パッチを作る
Submit Repoでテスト
MLでレビュー

Submit Repo
• 絶対にコケてはいけないテストを
自動で行ってくれるリポジトリ
• http://hg.openjdk.java.net/jdk/submit
• 試験対象はOracle JDKがサポートするプラットフォーム
• Linux x64、Solaris SPARC V9、Windows x64、macOS
• レビューはSubmit Repoのテストが終わってから
回すのがマナー
• 試験結果はメールで返ってくる

Submit Repoの結果メール
失敗している場合成功している場合

コードレビューサーバ
• http://cr.openjdk.java.net/~<ユーザー>/
• Author以上が利用できる
• OpenJDKのパッチレビューは
webrevをここへUpすることで行われる
• webrev: OpenJDKコミュニティのレビューフォーマット

webrev

基本的な流れ：修正の反映
• Committer以上の仕事
• レビューでOKが出たら
コミットしてPushする
• バックポートすべき修正は
JBSでリクエストを作る
• 基本的にはJBSチケットに
ラベルを付け、理由等を
書き込むだけ
コミット
プッシュ
（バックポート）

バックポートの例
① jdk<バージョン>-fix-requestラベルをつける
② バックポートしたい理由や
テストについてコメント欄に書く
③ jdk<バージョン>-fix-yesラベルが
ついたらバックポートOK

OpenJDKはじめの一歩

コントリビューターとしてのパッチ提案の流れ
1. OCAを提出する
2. 問題と、それを修正するパッチを
メール本文にベタ書きしたものを議論対象のMLに流す
3. 修正にポジティブな感触なら（まだいなければ）
Sponsorの募集とJBSへの登録をお願いする
4. コメントを反映してはパッチ送って…を繰り返す
– Sponsorとの共同作業
5. Sponsorに完成版パッチをPushしてもらう

ネタを見つけるコツ

再掲：使うからこそ思うこと
• こうだったらもっと使いやすいのに
• この部分、こう書きかえればもっとよく動くんじゃ？
• ここの動き、ヘンじゃね？
• このマニュアルわかりにくい
実はこれこそがネタ！
※感じ方には個人差があります

ネタは日々の生活の中に
• プログラマの人
• 使いにくい、動きがヘン、ドキュメントが間違ってる
• 運用の人
• 安定性、メトリクスのとりやすさ
• トラブルシューターの人
• デバッグのしやすさ、バグ修正

starterラベル
• コントリビューションのはじめの一歩
• 他コミュニティでも同様の仕組みがあることも
• たまに高難度なものが混ざっているので、注意！

OSSやってみる～OpenJDKの場合～（Java女子部 OSS開発はじめのいっぽ勉強会講演資料）

Recommended

Recommended

More Related Content

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)