読者です 読者をやめる 読者になる 読者になる

OSSにPull Requestを出すパターン

表題について、OSS Gate やその他での FAQ っぽくなってきたので記しておく。

travis の設定がある時点の Travis CI と合っていない

GitHub 上の対象リポジトリの CI が壊れているのを見つけるのが基点になる。対象の Travis CI のエラーログを見て失敗の原因を見てみるのが初手。最近だと .travis.yml の設定がある時点の Travis CI と合っていない現象としてこういったものがあったりするので、調査をして .travis.yml を変更した PR を出す。CI をパスしなければ継続調査となる。

このケースはだいたいテストの実行以前の bundle install 周辺で落ちていることが多い。

既存のテストが落ちている

達人プログラマーにも書かれているいわゆる割れ窓理論。CI でのテストが落ちているようであれば、手元に持って来たコードで同様にテストが落ちることを確認して、テストをパスさせて PR を出す。

依存ミドルウェアとのバージョンが噛み合ずに CI のテストが落ちている

依存ミドルウェアのある Gem で CI が落ちていて、手元でのテストがパスする場合は Travis CI 上で使っているミドルウェアのバージョンを見てみて、バージョン齟齬があるようであれば .travis の before_script あたりを変更することになる。

RailsRuby のバージョンが合わない

Rails 5 では Ruby 2.2.2 以降のみサポートしているため、その要件を満たさずにエラーになっている場合がある。.travis.yml の matrix にある allow_failures をメンテナンスして PR を出す。

Travis CI の Ruby のバージョンがメンテナンスされていない

いまだと Ruby 2.4.0 対応していない .travis.yml のプロダクトがそれなりにあると思うので、README.md にサポートしている Ruby バージョンが示されているようであればそれも合わせて変更した PR を出す。もちろん手元で対象の Ruby バージョンで動くことを見てから PR を出すのは大前提で、もし動かなければその修正も行なった PR にする。

EOL の Ruby が落ちている

EOL の Ruby をパスさせるのが大変そうであれば、メンテナンスコストと秤にかけてドロップすることを提案した PR を出す。EOL の Ruby をどう扱うかはオーナー次第なので回答にあわせてどうするか検討を進めていくことになる。

Rails のアップグレードで動かない

Rails アプリケーションで Rails のバージョンを上げたら動かないといった際に、Gem が対象の Rails のバージョンに対応していないようであれば対応して PR を出す。

テストを実行すると警告が発生する

テスト実行辞意 Ruby 本体、RSpec あるいは MiniTest が出力する警告があれば消す。特に Ruby 本体が出す警告は、その Gem なりを使う側のアプリケーションでも出力されている可能性があるため有用な PR になると思う。

Edge Ruby でテストが落ちる

手元で ruby 2.5.0dev を使って、テストがとおらない Gem があれば調査をする。Edge Ruby が原因で動かないといったことは (経験上) 滅多になく、単体の Gem 基点ではなかなか見つかるものではないので、使っている Rails アプリケーションで Edge Ruby を使った際に何らかの不具合があれば対応するといった流れ。必要に応じて、bugs.ruby-lang.org への ISSUE なども検討することになる。

typo の修正

SSIA.

機能提案をする

自分が欲しい機能がないのであれば、その機能があると良い背景を説明した PR を出す。機能提案は上記のような expected に actual を合わせに行くといったものとは違い、as-is より to-be の方が優れているなぜならばといった話の流れになるため、やや上級者向きだと思っている。余談だが、Rails のように多数のコンポーネント間での相互作用が多い Gem よりも、RuboCop のように新たな Cop を add-on できるような Gem の方が機能提案はしやすいように感じているが、このあたりは個人差がありそう。


ぱっと思い当たるあたりだとこのあたりになる。自分が PR を出している経験則を元にしているので、これ意外にも多くのパターンがあると思う。

おまけ

使っているアプリケーションの Gemfile.lock に書かれている (gem でインストールする) プロダクトについて、対象を手元でパッと探索、確認、変更できるように ghq + gem-src の環境を作っておと PR が捗るのでオススメ。

ghq と gem-src については過去のエントリ参照。

koic.hatenablog.com