PHPerKaigi 2022にて発表するスライドです。 https://phperkaigi.jp/2022/
bugs.php.netからGitHub Issuesへと変更されたという内容のトークです。
2022年版php-srcのバグ報告の仕方
View Slide
自己紹介てきめん● https://tekitoh-memdhoi.info● @youkidearitai● https://github.com/youkidearitai● https://www.youtube.com/user/tekitohmrp● https://www.nicovideo.jp/user/2957748● 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へアクセスすると、該当のIssuehttps://github.com/php/php-src/issues/8059へリダイレクトされる。
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.netMost recent open bugs8.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を立てたが、PullRequestまで行っても良かったことがわかった。文章がおかしかったら修正してくれる。みんな助けてくれる。● OSSはできる貢献はそれぞれ違うけど、それぞれができることをやるのが良いのではないか。
まとめ● バグの報告を行う際には、現状bugs.php.netとGitHub Issuesを見て同じ報告がないかチェックする必要がある● チケット番号は、bugs.php.netの場合「#xxxx」、GitHub Issuesの場合「GH-xxxx」となる● もっと気軽にIssueやPull Request投げてもいいんだなって思った● 過渡期なので色々と大変かもですが頑張りましょう● php-srcのバグ報告のみならず、貢献できることを探してみませんか?
おしまい貢献の参考になれば幸いです。自分のペースでできることを貢献できるといいですよね