初めてOSSに貢献した話
先日、初めて大規模なOSSに貢献をしました。これまでにも個人管理のレポジトリにプルリクを出したことは何度かありましたが、企業主体のちゃんとしたOSSへの貢献は初めてでした。本格的なOSSとなると個人管理のOSSレポジトリへの貢献とはだいぶ異なる点やわからないことが多かったので、その経験をここに書いていきます。
貢献先
貢献をしたレポジトリはMicrosoft社のDeepSpeedです：
DeepSpeedライブラリは複数のGPUノードを使うような、大規模ニューラルネットワークの学習や運用に使われるもので、近年流行りのLLM研究でも主流となっているライブラリです。自分も研究インターンや、大学院での研究で使っています。（DeepSpeedライブラリやその裏にある技術についてはQiita記事にまとめているので、気になる方はそちらをご参照ください。）
修正箇所
自分が修正したのはとても単純なもので、GPUノード間通信に用いられるssh/pdsh port番号をユーザー指定可能にした、というだけです。通常、sshのportは22が使われることが多いですが、セキュリティ等何らかの理由でportが22以外に設定されることがあります。DeepSpeedライブラリはport番号が指定できない仕様になっていたので、これを修正し、プルリクを出しました。
プルリクを通して学んだこと
- ちゃんとしたOSSのcontribution guidelineはどんなものか
- コードの追加先はよく考えて選ぶ
- 自分の修正に応じてテストコードも書き換える
- 返信が遅いからと言って無視されているわけではない
1.ちゃんとしたOSSのcontribution guidelinesはどんなものか
DeepSpeedにはContributionのガイドラインがあり、ここにはプルリクを出す前にまずするべきことが書かれていました。
- pre-commitを用いてコードのformatを統一する。pre-commitの設定を一回すると、
git commitをする度にコードformatの検証プログラムが走り、format規格に準じていない場合はgit commitが弾かれる。ありがたいことに、弾かれた場合は必要な修正も自動的に行なってくれるので、再度git addgit commitをすれば良い。 - pytestを用いてtestを行う。今回はunit-testとmodel-testの両方があった。
2.コードの追加先はよく考えて選ぶ
今回は、愚直にssh実行ファイルに自分の修正を加えてプルリクを出しましたが、管理者の方から実行ファイル内で呼び出されるクラスそのものが定義されているファイルに変更をまとめて欲しい、というFBをいただきました。振り返ってみればかなり当たり前な指摘ですが、ライブラリの拡張性や保守性に合わせてプルリクを設計することの大切さが学べた気がします。
3.自分の修正に応じてテストコードも書き換える
FBを元に自分が加えた修正によって一部関数の返り値が変わったため、unit testに通らなくなりました。普段開発はあまりしないので、testスクリプトは勝手に書き換えてはならないものだと勝手に思い込んでいたのですが、管理者の方からtestスクリプトも書き換えるよう言われ、testスクリプトを書き換えました。これも慣れている人からすれば初歩的なことかもしれませんが、自分にとっては学びでした。
4.返信が遅いからと言って無視されているわけではない
指摘されたFBを元にプルリクを洗練し、unit testも全て通るようにしても、なかなかプルリクが承認されませんでした。「あれ、放置されてる...?」と少し不安になったのですが、しばらくすると管理者の方から「遅くなってごめん！先にこちら側で確認したいことがあった！」と連絡があり、ホッとしました。大規模なOSSとなると、OSSの今後の計画等との兼ね合いも考える必要があるのでしょう(?)。
全体を通して
コード数行分の小さな修正ではありましたが、やはりプルリクが通ると嬉しかったです。また管理者の方々からは様々なFBをいただくことができ、綺麗なコードの書き方について少し勉強できた気がします。「大企業のレポジトリへのプルリクが承認された」というのは自分に対する自信にも繋がったので、そういった意味でも良かったと思います。
これからもどんどんOSS貢献していきます💪
Discussion