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

PHPerKaigi 2022にて発表するスライドです。
https://phperkaigi.jp/2022/

bugs.php.netからGitHub Issuesへと変更されたという内容のトークです。

Transcript

1. 2022年版php-srcの バグ報告の仕方
2. 自己紹介 てきめん • 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個見つけた
3. PHPのバグ報告の方法 bugs.php.netからGitHub Issuesへと変更された PHP RFC: Migrating to GitHub Issues
4. 前段階として • ソースの正がgit.php.netからGitHubのphp/php- srcへと変更された – 2021年3月末の、git.php.netがクラックされてしまい、 悪意あるコードが注入された事件への対処 – 直接は無関係だけど、ここでGitHubが正となったのが 前段階
5. 事のあらまし • bugs.php.netはオリジナルのシステムなのにメンテナン スされていない(git.php.netの二の舞になるかも) • 悪意ある報告に悩まされている(スパム、なりすまし…) • bugs.php.netでの報告の方法が独特でハードルが高い • Pull RequestをGitHubで受け入れており、Issueも GitHubにすればPRとIssueをリンクさせやすい
6. GitHub Issuesに移転された • 故にGitHubで運用しているのだからIssueも運用しよう • ただし、bugs.php.netの役割が終わったわけではない – セキュリティ上の問題は引き続きbugs.php.netで行う (GitHubではクローズドなIssueの報告ができない) – bugs.php.netに残されたバグはそのまま参照される • https://bugs.php.net/77165 closeされたチケットも従来どおり参 照できる
7. チケット番号が異なる • GitHubへの移行により、GitHub Issuesのチケット番 号と、bugs.php.netのチケット番号が違うという問題 – GitHub Issueの方に「GH」というプレフィックスがつく • 「GH-xxxx」などとなってる • NEWSファイル、コミットログで確認できる • ChangeLogページではリンクによる代替でプレフィックスがつい てない
8. このように、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 へリダイレクトされる。
9. bugs.php.net発のバグ (#80000番台) GitHub Issues発のバグ (#7000番台)
10. 便利だなって思う点 • GitHubのリポジトリをWatchしておけば、IssueもPull Request も見られて何が起こっているのかわかりやすくなった – bugs.php.netはどういうIssueが出されたか分かりづらかった • GitHubのリソースが使える – 貢献を可視化できるようになった – ログインや、ソースのコミット権限などのリソースが使える – つまり便利になりましたね
11. 辛い点 • bugs.php.netにあるバグが無くなったわけではないため、 bugs.php.netの修正のプルリクエスト・コミットも来る – ChangeLogがごっちゃになる • 現状の判別方法ではリンクもしくは4桁か5桁か – バグ報告するとなるとbugs.php.netも見てGitHub Issuesも見 て似た問題がないか調べないとならない – こればかりは過渡期なので仕方がない
12. 現状(2022/03/17現在)のbugs.php.net Most recent open bugs 8.0まではあるが、8.1以降はない (upstreamへ反映されるという可能 性はある)
13. バグ報告の方法を考えてみる 1 • バグを発見する • バグの再現できる最小のコードを見つける • バグが重複していないか調べる – bugs.php.net より検索して調べる – GitHub Issues より検索して調べる ここが面倒そう
14. バグ報告の方法を考えてみる 2 • Titleをわかりやすくまとめて書く • Descriptionに、再現するコードと、ActualとExpectedを書く • PHPのバージョンが最新のバージョンか調べる • OSも確認できればしておく、最低限再現したOSを書く • https://3v4l.org も使おう、バージョン違いで出る可能性も あるし、検証もできる。
15. contributing guidelinesを見てた ここをクリックしたが、bugs.php.netのままだった 参考にしようと、ここを見た (CONTRIBUTING.md)
16. contributing guidelinesを見てた ここをクリックしたが、bugs.php.netのままだった
17. これは直したほうがいいと思ったので • Internalsのメーリングリストをひとまずさかのぼってみた が、特に言及が見つからなかった • GitHub Issuesで検索してみたが、見つからなかった • bugs.php.netで検索してみたが、見つからなかった • masterブランチ、php-8.1.4のタグや、php-8.0.17のタ グも見てみたが、変わっていなかった
18. Issueに残しました ラベルどうすればよかった かな？ 文章、これでいいのかなあ…？
19. 対応していただきました 1 ネイティブじゃないから躊躇し てたのだけど、細かい文言等は 修正してくれた このPR作ってくれた方は文言 そのままで対応してくれた。 →そんなノリでいいんだなって 思った
20. 対応していただきました 2 ラベルも修正してくれた 感謝をいいたくなったのでその 意を述べた
21. 感想 • 今回はドキュメントのIssueを立てたが、Pull Requestまで行っても良かったことがわかった。文 章がおかしかったら修正してくれる。みんな助けて くれる。 • OSSはできる貢献はそれぞれ違うけど、それぞれ ができることをやるのが良いのではないか。
22. まとめ • バグの報告を行う際には、現状bugs.php.netとGitHub Issuesを見て 同じ報告がないかチェックする必要がある • チケット番号は、bugs.php.netの場合「#xxxx」、GitHub Issuesの場合 「GH-xxxx」となる • もっと気軽にIssueやPull Request投げてもいいんだなって思った • 過渡期なので色々と大変かもですが頑張りましょう • php-srcのバグ報告のみならず、貢献できることを探してみませんか？
23. おしまい 貢献の参考になれば 幸いです。 自分のペースでできることを貢献できるといいですよね