Githubを使ってScalaの開発に貢献しよう
ScalaJP盛り上げよう企画として、Scalaブログリレーをちょっとやってみることにしました。ルールは簡単で、それぞれが好き勝手にScalaに(少しは)関係する話題を書いて、次に書く人を指名するというものです。指名された人は、7日以内に記事を上げるか、無理な場合、他の人を指名します。
言い出しっぺの法則、というわけで、まず第一弾を私が書いてみます。今回は、Scalaのバグなどを見つけた場合などに、どうやって実際にバグ報告・修正を行うか、という話です。
Scalaは、むかしむかし(というほど昔ではないですが)は、Scalaのお膝元EPFL辺りにある、SVNリポジトリを利用して、開発が進められていました。しかし、最近になって、Scalaの開発は完全にgithubに移行しました。現在、Scalaのリポジトリは、
https://github.com/scala/scala
にあり、Scalaの開発における中心的な人物、Paul Phillipsさんによって管理されています。あれ？開発者はMartin Odersky教授じゃなかったの？と思った方。実は、現在、Odersky先生は、
https://github.com/scala/scala
からforkした
https://github.com/odersky/scala
で主に作業を行っており、時折、scala/scalaの方にpull requestを投げています。
また、現在、Scala 2.10で取り込まれるかもしれないマクロ機能の開発が盛んですが、これは、
https://github.com/scalamacros/kepler
で開発が進められており、やはり同様に、scala/scalaに対してpull requestおよびマージが行われています。
さて、ここからが本題なのですが、githubに開発が移ったことで、Scalaのライブラリやコンパイラのバグを修正して直すための敷居は格段に低くなりました。昔、SVNで管理されていた頃は、コミット権限のある人以外は、バグ報告およびパッチを作成して、返事を待つしか無かったのですが、いまやgithub時代。自分のところにforkして、バグを修正してpull requestを送る事が非常に簡単にできるようになりました。
さて、contributeするとはいえ、手順がわからなければ不安だ、という方もいらっしゃると思うので、バグ修正などを行うときの流れをおおざっぱに書いてみます。
(1) Issue Trackerにバグ報告を行う
現在、Scalaのバグ管理は
https://issues.scala-lang.org/secure/Dashboard.jspa
でJIRAを使って行われており、アカウントを取得(その場で可能)さえすれば、誰でもバグ報告ができるようになっています。まず、発見したバグはここに報告するようにしましょう。一応、既知のバグでない事を確認するために、簡単に検索するのをオススメしますが、既知のバグである事を恐れすぎても仕方ないので、いくつかの関連キーワードでヒットしなかったら、恐れずにバグ報告をしてみましょう。
バグ報告はもちろん英語でする必要がありますが、何も恐れることはありません。
- 症状を再現するための最小限のコード
- 再現環境(Scalaのバージョン、Java SEのバージョン)
さえ、きっちり書けば、英語はへたくそでも、大体意図は伝わります。それでも不安な人は、他の人のバグ報告の文面を元に、自分の遭遇したバグに合うように書き換えれば良いでしょう。
(2) 返事を待つ
コメントが付いた場合、Issue Trackerにアカウントを登録したときに同時に登録したメールアドレスに対して通知が来ます。コメントは、
- 既知のバグ(に見える)だよ
- それバグじゃないよ
- trunk(master)だと直ってるよ
- バグ(っぽい)だね
の４つくらいに大別されます(細分化すればもっとありますが)。
既知のバグだよ、と言われた場合、そのバグIDへのリンクが貼られているので、そこを覗いて、同じっぽいと思ったら、そちらが直されるのを待つか、次の修正フェーズに移ります。
それバグじゃないよ、と言われた場合ですが、実際にはコメントした人が勘違いしていて、バグである事もあるので、本当にそうか確かめてみましょう。
trunkだと直ってるよ、というのは、安定バージョンでバグに突き当たって報告したときに来る、ありがちなリプライで、この場合、素直に次の安定板がリリースされるのを待つか、バグの回避策を講じるしかないでしょう。
バグっぽいと言われた場合、どの辺でバグってるっぽいかを含めてコメントしてくれる場合もあるので、その辺りを参考にして、自分で直せそうに無ければ、誰かが修正してくれるのを待つのもテでしょう。
(3) 自分のアカウントにforkする
(2)で、バグっぽいという事が確定して、自分で修正する気になった場合、まず、
https://github.com/scala/scala
から自分のアカウントにリポジトリをforkしてください。githubならforkボタン一発なので簡単です。間違っても、いきなりscala/scalaそのものをいきなりcloneして修正しようとしないでください。scala/scalaを直接修正する権限がある人は少数ですから、修正してもそれを直接pushできませんし、scala/scalaの変更に追随するのが面倒になるだけです。
(4) ローカルにcloneする
forkしたら、git cloneでローカルにcloneしてください。
(5) 修正用トピックブランチを作成して、作業する
gitを使った開発では当たり前ですが、バグ修正はいきなりmasterブランチでやらずに、必ずブランチを作成して行うようにしてください。トピックブランチを用いた修正作業の方法については、Scala特有ではないので、省略します。
(6) テストを書く
問題が修正された事を確かめるためのテストを書きます。Scalaの場合、ライブラリ部分の修正に関しては、
https://github.com/scala/scala/tree/master/test/files/run
にテストを置くことが多いようです。
(7) pull request用ブランチを作成する
トピックブランチをそのままpull requestするのは避けて、トピックブランチを元にpull request用ブランチを作成するのが良いでしょう。Scalaのブランチ名は、コミットログを見る限り、人によって異なるようですが、わかりやすいように、
pullrequest/$(fixed-problem)
とするのが良いでしょう。プレフィックスは、pullrequest/の他にも、issue/とか使っている人が居るようですが、あまり細かく拘らなくても良いと思います。
(8) pull requestする
pull request用ブランチを作成できたら、いよいよpull requestします。ポチッとな、でpull requestできるので、簡単ですね。
(9) 返事を待つ
pull requestに対してコメント等があった場合、githubの自分のアカウントに通知が来るので、コメントを見て、その後の対応を考えましょう。私の場合、初回 pull request時は、テストを書いていなかったため、「テスト書いてもう一度pull requestしてね☆」ということでrejectされました。問題が無いと判断されれば、黙ってマージされる事もあります。
というわけで、Scalaの開発に貢献するための、おおざっぱな手順を書いてみましたが、いかがでしたでしょうか。私はSVN時代は、バグ報告をするだけで、特にコミッタというわけではありませんでしたが、案外簡単にpull requestを取り込んでもらえました。基本的に、手順さえ踏めば、無名であろうと、取り込んでもらえる事は少なく無いようです。
次は、このアイデアを出してくれた張本人ということで、 @everpeaceさん、お願いします。
参考URL：
