2022年版php-srcの バグ報告の仕方

自己紹介 てきめん ● https://tekitoh-memdhoi.info ● @youkidearitai ● https://github.com/youkidearitai ● https://www.youtube.com/user/te kitohmrp ● https://www.nicovideo.jp/user/29 57748 ● php-srcのバグは2個見つけた

PHPのバグ報告の方法 bugs.php.netからGitHub Issuesへと変更された PHP RFC: Migrating to GitHub Issues

前段階として ● ソースの正がgit.php.netからGitHubのphp/php- srcへと変更された – 2021年3月末の、git.php.netがクラックされてしまい、 悪意あるコードが注入された事件への対処 – 直接は無関係だけど、ここでGitHubが正となったのが 前段階

事のあらまし ● bugs.php.netはオリジナルのシステムなのにメンテナン スされていない(git.php.netの二の舞になるかも) ● 悪意ある報告に悩まされている(スパム、なりすまし…) ● bugs.php.netでの報告の方法が独特でハードルが高い ● Pull RequestをGitHubで受け入れており、Issueも GitHubにすればPRとIssueをリンクさせやすい

GitHub Issuesに移転された ● 故にGitHubで運用しているのだからIssueも運用しよう ● ただし、bugs.php.netの役割が終わったわけではない – セキュリティ上の問題は引き続きbugs.php.netで行う (GitHubではクローズドなIssueの報告ができない) – bugs.php.netに残されたバグはそのまま参照される ● https://bugs.php.net/77165 closeされたチケットも従来どおり参 照できる

チケット番号が異なる ● GitHubへの移行により、GitHub Issuesのチケット番 号と、bugs.php.netのチケット番号が違うという問題 – GitHub Issueの方に「GH」というプレフィックスがつく ● 「GH-xxxx」などとなってる ● NEWSファイル、コミットログで確認できる ● ChangeLogページではリンクによる代替でプレフィックスがつい てない

このように、NEWSファイルでプレ フィックスGHのついたチケット番号 を確認できる。 https://php.net/77165 へアクセスすると https://bugs.php.net/bug.php?id=77165 へリダイレクトできるように、 https://php.net/GH-8059 へアクセスすると、該当のIssue https://github.com/php/php-src/issues/80 59 へリダイレクトされる。

bugs.php.net発のバグ (#80000番台) GitHub Issues発のバグ (#7000番台)

便利だなって思う点 ● GitHubのリポジトリをWatchしておけば、IssueもPull Request も見られて何が起こっているのかわかりやすくなった – bugs.php.netはどういうIssueが出されたか分かりづらかった ● GitHubのリソースが使える – 貢献を可視化できるようになった – ログインや、ソースのコミット権限などのリソースが使える – つまり便利になりましたね

辛い点 ● bugs.php.netにあるバグが無くなったわけではないため、 bugs.php.netの修正のプルリクエスト・コミットも来る – ChangeLogがごっちゃになる ● 現状の判別方法ではリンクもしくは4桁か5桁か – バグ報告するとなるとbugs.php.netも見てGitHub Issuesも見 て似た問題がないか調べないとならない – こればかりは過渡期なので仕方がない

現状(2022/03/17現在)のbugs.php.net Most recent open bugs 8.0まではあるが、8.1以降はない (upstreamへ反映されるという可能 性はある)

バグ報告の方法を考えてみる 1 ● バグを発見する ● バグの再現できる最小のコードを見つける ● バグが重複していないか調べる – bugs.php.net より検索して調べる – GitHub Issues より検索して調べる ここが面倒そう

バグ報告の方法を考えてみる 2 ● Titleをわかりやすくまとめて書く ● Descriptionに、再現するコードと、ActualとExpectedを書く ● PHPのバージョンが最新のバージョンか調べる ● OSも確認できればしておく、最低限再現したOSを書く ● https://3v4l.org も使おう、バージョン違いで出る可能性も あるし、検証もできる。

contributing guidelinesを見てた ここをクリックしたが、bugs.php.netのままだった 参考にしようと、ここを見た (CONTRIBUTING.md)

contributing guidelinesを見てた ここをクリックしたが、bugs.php.netのままだった

これは直したほうがいいと思ったので ● Internalsのメーリングリストをひとまずさかのぼってみた が、特に言及が見つからなかった ● GitHub Issuesで検索してみたが、見つからなかった ● bugs.php.netで検索してみたが、見つからなかった ● masterブランチ、php-8.1.4のタグや、php-8.0.17のタ グも見てみたが、変わっていなかった

Issueに残しました ラベルどうすればよかった かな？ 文章、これでいいのかなあ…？

対応していただきました 1 ネイティブじゃないから躊躇し てたのだけど、細かい文言等は 修正してくれた このPR作ってくれた方は文言 そのままで対応してくれた。 →そんなノリでいいんだなって 思った

対応していただきました 2 ラベルも修正してくれた 感謝をいいたくなったのでその 意を述べた

感想 ● 今回はドキュメントのIssueを立てたが、Pull Requestまで行っても良かったことがわかった。文 章がおかしかったら修正してくれる。みんな助けて くれる。 ● OSSはできる貢献はそれぞれ違うけど、それぞれ ができることをやるのが良いのではないか。

まとめ ● バグの報告を行う際には、現状bugs.php.netとGitHub Issuesを見て 同じ報告がないかチェックする必要がある ● チケット番号は、bugs.php.netの場合「#xxxx」、GitHub Issuesの場合 「GH-xxxx」となる ● もっと気軽にIssueやPull Request投げてもいいんだなって思った ● 過渡期なので色々と大変かもですが頑張りましょう ● php-srcのバグ報告のみならず、貢献できることを探してみませんか？

おしまい 貢献の参考になれば 幸いです。 自分のペースでできることを貢献できるといいですよね