それが僕には楽しかったんです。

僕と MySQL と時々 MariaDB

OSS にちょっと技術的な貢献するまでの流れ

MySQL

はじめに

どうも、最近 Hulu でナルトが全話配信されていることに気がつき週末を溶かしたけんつです。
以前、MySQL の公式 Docker イメージにプルリクを投げたらようやくマージされたので、何をやったのか流れをまとめようかなと思って書いている。

よく「OSS に貢献してみよう」と言われるとドキュメントの翻訳や修正などが手頃で OSS 貢献の入門には丁度良いと言われる。
もう少し技術的なプルリクを出したい時にどうすればいいかは情報がなかったので、それらに意欲がある人に向けて少しでも役に立てばというモチベーションで書いている。

やったこと

github.com

MySQL の公式 Docker イメージに設定することが非推奨になっているオプションが明示的に設定されている箇所を見つけたので、該当するオプションを削除するプルリクを出した。

プルリクエストを投げるまでの流れ

問題が見つかる

MySQL の勉強をしようと思って Docker イメージを起動してログを見ていたら素のイメージでも Warning がいくつか発生していることに気がつき全部原因を調べればそれなりに勉強になると思って原因を調べることにしたのだが
そのなかで、どうやら非推奨オプションを明示的に指定しているとわかったので余計なログを抑制する名目で修正することにした。


Warning が発生している場合は非推奨の何かを使っていることがあり、それらは将来的に修正することがあったりする。
なのでそういう場合は積極的に修正しても良いし、何よりバグ見つけて貢献より圧倒的にハードルが低いがドキュメント修正よりは技術的な内容になりがちなのでおすすめしたい。

信頼できる情報をまとめておく

今回は該当するオプションが非推奨であることが MySQL 8.0 の公式ドキュメントとリリースノートに記載されていたのでそれを根拠に修正を進める。
後々、プルリクの概要欄などに使えるのでどこかにメモしておくと良い。

Symbolic link support as described here, along with the --symbolic-links option that controls it, is deprecated and will be removed in a future version of MySQL. In addition, the option is disabled by default.
https://dev.mysql.com/doc/refman/8.0/en/symbolic-links-to-tables.html:

Symbolic link support as described at Using Symbolic Links for MyISAM Tables on Unix, along with the --symbolic-links option that controls it, is now deprecated and will be removed in a future MySQL version. In addition, the option is now disabled by default. The related have_symlink system variable also is deprecated and will be removed in a future MySQL version.
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-2.html:

リポジトリを fork する

対象のリポジトリを fork する。
今回 fork したのは以下の対象となる以下のリポジトリ。
github.com


fork したやつがこれ。このリポジトリに修正を加えていく。
github.com

README を確認する。

README の Contribute みたいな項目を設けている場合は、プルリクにどういう要件があるのか明記されていることが多いので確認する。
それに従わないと修正してもマージされないことがあるので確認する。

今回は特になかったが、例えば以前ドキュメントにプルリクを出した thephpleague/oauth2-client では以下のようにコントリビュートの要件がかなり明確に決められている。

Contributing

Contributions are welcome and will be fully credited.

We accept contributions via Pull Requests on Github.

Pull Requests

  • PSR-2 Coding Standard - The easiest way to apply the conventions is to install PHP Code Sniffer.
  • Add tests! - Your patch won't be accepted if it doesn't have tests.
  • Document any change in behaviour - Make sure the README and any other relevant documentation are kept up-to-date.
  • Consider our release cycle - We try to follow SemVer. Randomly breaking public APIs is not an option.
  • Create topic branches - Don't ask us to pull from your master branch.
  • One pull request per feature - If you want to do more than one thing, send multiple pull requests.
  • Send coherent history - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please squash them before submitting.
  • Ensure tests pass! - Please run the tests (see below) before submitting your pull request, and make sure they pass. We won't accept a patch until all tests pass.
  • Ensure no coding standards violations - Please run PHP Code Sniffer using the PSR-2 standard (see below) before submitting your pull request. A violation will cause the build to fail, so please make sure there are no violations. We can't accept a patch if the build fails.

Testing

The following tests must pass for a build to be considered successful. If contributing, please ensure these pass before submitting a pull request.

$ ./vendor/bin/parallel-lint src test
$ ./vendor/bin/phpunit --coverage-text
$ ./vendor/bin/phpcs src --standard=psr2 -sp

Happy coding!

https://github.com/thephpleague/oauth2-client/blob/master/CONTRIBUTING.md

過去にマージされた修正から傾向を掴む

もし明確なコントリビュートの要件がない場合は、過去にマージされたプルリクから何があるとレビュワーにとって嬉しいのかを判断できる場合があるので見てみると良い。
ブランチの命名規則や、プルリクの概要、コミットの粒度など。

ある程度みたら何がクローズされているかも見れば、修正は正しいがマージされないケースを知ることができることがある。
master ブランチにプッシュしているなど。

問題箇所を修正する

ブランチを切る

コントリビュートの要件にしたがってブランチを切る。
今回は特になく、fork したリポジトリの master ブランチからプルリクを飛ばしても良いみたいだったのでそうしている。

修正する

問題の箇所を修正する。

今回は以下の設定を削除している。
github.com

ビルド、テスト、実行

ビルドが通り、テストをパスし、実行しても不具合がないことの確認をする。

今回は Dockerfile からイメージをビルドして、docker run している。
その段階でログを確認して、対象の Warning が出力されないことを確認している。
CI を利用していたので、正しく動作していることが確認できたらプッシュして、CI でテストがパスされればここのフェーズは完了。
テストが落ちた場合は、適宜修正する。

プルリクを作成する

プッシュしたら Github の Web UI からプルリクを作成できるので実行する。
その段階でプルリクの概要を記載する必要がある。

概要を記載する

ここは空でもいい場合があるが、自分は空でいい場合でも書く派なので書く。
何を書くかというと以下の３点を意識すると良いと思う。

  • プルリクで何を修正、追加したのか(この時判断材料となるドキュメントがあれば載せる)
  • 予期する結果がどういうものか(ログや実行結果など)
  • 必要となる設定、変更後の利用方法(ビルド方法など、利用方法に変更がある場合)

ここまで書いたらプルリクの作成を完了する。

マージされることを天に祈る

レビューが返ってきたら、適宜修正する。


やることをやり切ったらあとは祈るだけ。

まとめ

  • Warning はバグ潰しよりも遭遇し、非推奨の何かが絡んでくることが多く修正しやすい
  • コントリビュートの要件は遵守する
  • 概要は要点を抑えてしっかり書く

余談

書いていて思ったがバグに遭遇した場合も検証したことはないが、今までみた OSS のプルリクをみる限りこれでいけると思う。