Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

D5c60d3b90d3e0ad0c190adb197e45d1?s=128

てきめん tekimen

April 10, 2022
Tweet

More Decks by てきめん tekimen

Other Decks in Technology

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. おしまい 貢献の参考になれば 幸いです。 自分のペースでできることを貢献できるといいですよね