Apache Arrowの開発に参加している須藤です。現時点でapache/arrowのコミット数は1位です。私はRubyでデータ処理できるようになるといいなぁと思ってApache Arrowの開発に参加し始めました。同じような人が増えるといいなぁと思ってなにか試したりしましたが、あいかわらず、今でも実質1人でApache ArrowのRuby対応をしています。何度目かの「もっと仲間を増やさないと！」という気持ちになったので、最近の活動を紹介して仲間を増やそうと試みます。
Apache Arrowの開発でなにをがんばっているかを考えてみたところ、レビューを頑張っているなぁと思ったので紹介します。あと、レビューする人が足りないなー、増えるといいなーと思っているので、今日はレビューの話にします。なお、この一連の話を書き始めてから@hiroysatoが興味を持ってくれて、プルリクエストを送りはじめてくれました。現時点で16個です。慣れてきたらレビューもしてくれるといいな。今は、そもそもRuby関連のプルリクエストが少なくてレビューもなにもないけど。。。
Apache Arrowとレビューと私
Apache Arrowはだいたい3-4ヶ月ごとにリリースしていて、毎回100人弱の人が500強コミットしています。たとえば、この間リリースされた18.0.0では89人が530コミットしています。（Dependabotくんが一番頑張っています。）
https://arrow.apache.org/release/18.0.0.html
This release includes 530 commits from 89 distinct contributors.
500強のコミットがあるということは、500強のコミットをマージした人たちがいるということです。（Dependabotくんのプルリクエストのマージも含めて）私が1/5くらいをマージして、マージ数でいうと一位です。ということは、私は結構レビューしている方なはずです。
https://arrow.apache.org/release/18.0.0.html
$ git shortlog -sn --group=trailer:signed-off-by apache-arrow-17.0.0..apache-arrow-18.0.0 137 Sutou Kouhei ...
ということで、Apache Arrow固有だったり固有じゃなかったり、レビューに関して紹介します。
Apache Arrowとレビューとペース
Apache Arrowは基本的にすべての変更はプルリクエストを作ってからmainにマージします。一部、リリース関連の定形変更は直接mainにプッシュしますが、基本的にはプルリクエストを作ります。
基本的に、他の人がレビューしてからマージしたほうがいいよね、ということにはなっています。しかし、レビューする人が足りていないので、コミット権を持っている人は他の人のレビューなしで自分のプルリクエストをマージすることがあります。ただ、その場合も、数日待ってからマージすることが多いです。明らかにこれで大丈夫だよね、今のままだとCIも壊れててアレだし、みたいなやつは待たずにすぐにマージすることもありますが、基本的には数日単位でプルリクエストが進んでいきます。
同じ会社で同じ時間帯に働いているチームにとってはこの時間の進み方は「ゆったりしてるなー」という気持ちになると思います。そういうチームではプルリクエストを作ってすぐにレビューしてちょろっと直してマージとかできるからです。
しかし、Apache Arrowを含むApache Foundation傘下のプロジェクトは世界中のあらゆる人が開発にできることを重視しているので、前提が変わってきます。まず活動時間帯が違います。日本とヨーロッパでは8時間くらい時差がありますし、日本とアメリカでは半日くらいの時差があります。活動時間帯が違うので同期的なやりとりはできません。テキストベースで非同期にやりとりすることになります。プルリクエストのコメントやメールでのやりとりの1ターンに1日かかるのは珍しい光景ではありません。
Apache Arrowの開発に参加している人は日本のタイムゾーンに近い人たちよりも離れている人たちの方が多いので、私のコメントに対するお返事は私が寝ている間にされていて、私は次の日確認する、という流れになることが多いです。慣れていないと、なかなか進まないなーとやきもきしますが、慣れてくるとやきもきせずに過ごせるようになります。
ということで、1つのプルリクエストをマージするために数日かかるのはよくあることなので、1ターンに1日というペースでレビューすることになります。1つのプルリクエストでのやりとりだけをずっと続けるということは滅多にありません。一日の作業量が減るので楽になりやすいということです。
しかし、マージまでに何週間もかかってくると大変になります。どうして大変なのでしょうか。
プルリクエストの粒度とレビュー
何週間も続くプルリクエストはだいたい変更量が大きいです。変更量が多いプルリクエストはレビューが大変なんです。
どうして大変かというと、まず、単純に読まないといけない変更点が多いので時間がかかるからです。また、多くの場合、変更量が多いほどコメントが必要な箇所も多くなりやすいので、コメントを書く時間もかかります。また、方向性が違ったときのダメージが大きいです。変更量が多いということは、結構がんばっているので、「これ、方向性変えたほうがよくない。。。？」と言うのも気が引けます。だからといって言わないということはなくて言うのですが、それなりの量の説明を書かないといけないことが多いので、やっぱり時間がかかります。
では、どうするかというと、細かい話をする前に、もっと分割できない？という話をします。たとえば、apache/arrow#37696はPyodideに対応したいというプルリクエストだったのですが、C++実装のビルドプロセスにも手を入れるし、Python実装にも手を入れるし、ビルドプロセスのいじりかたも筋がよくなさそうだし、とか、このまま進めるとしんどそうと私の直感が言っていたので、初手で分割をお願いしました。みなさんも、Apache Arrowに限らず、プルリクエストを送るときは全部入りのやつをどーん！と送るのではなく、レビューする人に優しい粒度で送るといいでしょう。少なくとも、私がレビューする人になりそうなプロジェクトにプルリクエストに送るときは小さくして！！！ただ、全体的な方向性を検討した上でレビューしたいという場合もあるので、その場合は議論のために全部入りのやつが必要になります。
なお、分割後のプルリクエストの1つがapache/arrow#37821なのですが、これはマージできる状態になるまでに5ヶ月くらいかかりました。途中でもっと分割しない？と何回か言ったのですが、分割せずに進んだんですよねぇ。。。
既存の開発スタイルとレビュー
1回のリリースごとに100人弱の人のコミットが含まれますが、その中には初めてApache Arrowにプルリクエストを送る人がたくさんいます。以下は1回だけコミットした人の数（53人）ですが、この中の多くは初めてプルリクエストを送った人だったはずです。
$ git shortlog -sn apache-arrow-17.0.0..apache-arrow-18.0.0 | grep ' 1 ' | wc -l
53
初めての人はApache Arrowでの開発スタイルをわかっていません。初めての人でもスムーズに開発に参加できるようにドキュメントを用意したり、ドキュメントを読まずに作業したらここを読んで調整してね！自動応答コメントを書いたりしています。が、こういうやつを読んでくれない人が多いんですよねぇ。どうしたらいいの？
手動で同じような内容をコメントしたりこっちで整えたりするのですが、すでにレビューする時間が足りていないので、こういうことに時間を使わないといけないのかーという気持ちになりながらやっています。
みなさんが各プロジェクトにプルリクエストを送るときは、そのプロジェクトが用意してくれているテキストを読んで従ってね！それがメンテナンスしている人たちの負荷を下げるはずだよ！
未テストとレビュー
最近では多くのプロジェクトでCIが整備され、既存の機能が壊れていないかだけではなく、コーディングスタイルが整っているかなどまでいろいろ自動でチェックできるようになっています。もちろん、Apache Arrowもそうなっています。
基本的にCIが通っていない状態ではマージしないので、レビュー前にはCIが通る状態になっていて欲しいです。もちろん、ここでテストが失敗するんだけど？どうして？ヒントもらえる？とかで一緒に解決していくのは大丈夫なんですが、CIの確認もレビューする人まかせにされると、変だなぁという気持ちになります。CIに時間がかかるので、CI結果を待っている間に先にレビューする人が見始めちゃったとかは別によいのですが、CI結果が出る前にレビューリクエストをして積極的にレビューする人の注目を集めるのは、ちょっとやりすぎじゃないかという気はします。CIの時間は結構潤沢に使える時代になりましたが、レビューする人の時間はまだ貴重なんですよねぇ。
GitHubのリポジトリーでは、初めてプルリクエストを出したリポジトリーのCIはリポジトリーの書き込み権限がある人が許可しないと動き出さない設定になっていることが多いですが、フォークの方のGitHub Actionsを有効にするとフォークの方で許可を待たずに結果を確認することもできるので活用してください。
まとめ
うーん、こんなことを書き連ねて開発に参加する人が増えるか。。。？という気持ちになってきたので、この辺にしておきます！なぜか「自分もレビューする人としてApache Arrowの開発に参加し始めるか！」という気持ちになった人はRed Data Toolsのチャットに来てください。その人に合わせてどのあたりからやるとよさそうかを提案します。
それはそうとして、apache/arrowコミット数1位の私にApache Arrow関連のサポートを頼みたいという場合はクリアコードのApache Arrowサービスをどうぞ。
