seri::diary

日常

ちょっとだけOSSに貢献したらすごく新感覚だった話

普段は仕事でコードを書いていて、それでおちんぎんは貰えるし、こんな自分でも多少は社会の役に立っているのではないかなぁという実感がまぁ多少は持てる時もある訳で、それなりに満たされた生活をしている。サラリーマンなので、当然大人の事情でしんどい気持ちでコードを書いてる時も少なからずあるが、それでも仕事は仕事である。頑張って書くのである。そんな毎日。

そんな中、1円ももらえないし、役に立つかどうか良くわからんが、気になったのでやった、というような状況でコードを書いてみたら、不思議な事に仕事でコードを書くのとは全く異なる満足感が得られてめっちゃテンション上がったので、その辺の話をしたい。

ある日、BigQueryにアクセスしている部分で突然エラーがraiseされてトラブったので調べてみたところ、GCPruby clientであるgcloudというgemがGoogleaccess tokenを取得する時に Faraday::TimeoutError をraiseしていたことが原因だった(因みにこの時のgcloudのバージョンは0.12)。 Faradayのエラークラスをそのままraiseしてくることを想定していなかったので、自前で入れていたリトライ機構をすり抜けてしまっていた。

gcloudのnamespace配下で定義された専用のエラークラスがあるにも関わらず、Faradayのエラーを生でraiseしてきたという状況が単純に気になって調べてみたところ、errorをraiseしてきたのはgcloud本体ではなく、そのgemが使っているauth用のクライアントであるgoogleauthというgemの方だった。ソースを読んだところ、確かにrequestする部分でエラーを拾ってない事がわかった。で、gcloud側もこのエラーを拾ってwarpしてない、という状況だった。

正直このエラーをどちらかにwrapしてほしい。Faradayのエラーがそのままraiseされてくるのは流石に想定しづらいし、何よりgoogleauthもgcloudも、独自のエラークラスを定義し、主要なエラーについてはそれでwrapしてraiseするように実装してるのだから統一してほしいというモンである。

しかし、今回見つけた問題に関してはどちらが面倒を見るのが良いのだろうか?個人的意見としては、auth周りで起きている問題なのでgoogleauthに面倒見てほしい。が、googleauthを使ってるgcloud側で面倒見てもまぁそこまで筋は悪くはない。

というようなことを考えていたら、gcloudのrepositoryですでに似たような問題でお悩み相談しているissueが立っていた。なんでFaradayのエラーが飛んでくんねんという話とhttp requestのエラーくらいretryするべきではという話がごっちゃになってややこしいのだが、少なくとも議論の終盤の流れとしてgcloud側が何か対応をする気はないらしかった。

ならば、googleauth側でやるべきことが大体わかってる自分がやるのが良いだろうと思い、googleauthの方にPRを出し、先日approveされた。googleの中の人(多分)のレビューともなると色々細かいツッコミが入るかなと思ったが割とあっさりとapproveされた。まぁ大した修正じゃないしな。

まだマージされていないが、このPR自体はgcloudの方で立っていた件のissueの方で紹介されて、この件はgoogleauthの方に責任を持たせてgcloud側の上記のissue自体をcloseする提案が出ている。大した修正ではないにせよ、半年ぐらい停滞していた議論を少しでもすすめるきっかけを作れたという結果には満足しているし、自分自身も困っていた問題なので、ぜひマージされてほしい。たのむ。

今回の件は多分誰でも出来たことではあったし、ブログのネタにするにはあまりにしょうもない話だったかもしれない。しかし、自分が問題だと感じていることに対して解決策を提示して、それをほかの人が(しかもgoogleの人が)認めてくれた、という結果が、とても嬉しかった。OSSにcontributeしても1円にもならない訳だが、なんというか、多くの人がOSS活動をしている理由が少しだけわかった気がした。

なお、調子にのってopenid-rubyという2年ぐらいメンテされてなかったOpenID(Connectではない方)のクライアントにもbugfixのPRを送ってみた。もうcommiterも放置しててマージしてもらえないかなと思ってたらちゃんとマージしてもらえた。こちらはたまたま壊れてたの見つけたから直したよ、という程度だったが、自分にすぐできるのはこういうことなので身の丈に合った仕事と言えるのかも知れない。

今後も何か自分にできそうなことがあれば積極的にPRを送ってみようと思えた。多分その方が仕事でコードを書くよりも下手すると楽しい。

2017年3月29日追記