MySQLのBug Report
もう一週間経ったけど、今回出したバグレポートでドキュメントが修正されました。めでたい。
単にドキュメントが修正されただけですが、せっかくなのでMySQLにBug reportするまでの流れを書いておきます。
アカウント登録
シュッと登録します
How to Report a Bugを読む
なにやら説明がありそうなので、読んでおきます。 なにか厳しい規則があるというわけではないので、チェックリスト的にさらっと読んでからレポートを書くと良さそうです。
The basics: what you did, what you wanted to happen, and what actually happened.
Always search the bug database first.
If you don't understand an error message, ask for help.
Be brief, but don't leave any important details out.
Use English.
Don't report bugs about old versions.
Only report one problem in each bug report.
Check out these other resources.
2つ目のbug databaseからの検索は、status
とseverity
をAllにして、かつ変数名などをフルで入力したほうがよさそうです。
↓ defaultではstatus: Active
, severity: Production Bugs
になっている
僕が今回レポートしたときはdefault_collation_for_utf8mb4
というvariableに関したことだったのだが、default_collation_for
までで検索すると結果が見つからなかった。。。
(このブログを書くときに気になってフルで入力したら何件かヒットしましたorz)
また、Check out these other resourcesはMySQLチームが書いているものではなく、OSSの一般的なものなので、How to Report a Bug
以外にも読むならMySQL道普請の梶山さんの記事を読むと良さそうです
Reportを書く
フォームに沿って書いていきます。
細かい文法が正しいか気になって永遠と悩んでも仕方がないので、ある程度伝わればよいかという気持ちで書きます(僕は)。
MySQL bugsを漁っていると「これ説明する気あるの?」みたいなレポートもあるので、状況説明ができていれば前置詞や助詞がただしいか、適切な動詞を選択できているのかなどを気にして悩む必要はないかと思います。
見守る
提出するとstatusがopenとなってMySQL Bugsで見られるようになります。 特に、自分の提出したbugはView your bugsからすぐに確認できます。
なにか進捗があれば登録したアカウントあてにメールが届くので、対応が求められる場合は適宜対応すれば良いと思います。
だいたいトリアージチームのUmeshさんにVerifiedされ、CategoryによってMySQLの内部のチームにフォーワードされるようです。
今回は単にドキュメントが修正される程度のものだったので、すぐに完了しました。
ドキュメントも翌日に確認したら更新されていました。
めでたい。
余談
今回はMySQL 5.7から8.0へのオンラインマイグレーションをする際に、万が一8.0では問題がおきて8.0 -> 5.7のレプリケーションを再度フェイルオーバするケースを想定して、default_collation_for_utf8mb4
をmy.cnfで指定しようとしていました。
どのvariableがオプション指定またはmy.cnfで指定できるのかを確認する方法を知らなかったので、すぐにbug reportするをひよって迷っていて、twitterに投げたところyoku0825さんから返信をいただけました。ありがとうございます!
Thank you tom__bo-san. But this is Not a bug.
— yoku0825 (@yoku0825) 2019年7月26日
This behavior is described in the Doc.
Cmd-Lineは受け付けないのでmy.cnfには書けませんね。 pic.twitter.com/HpNEjpWHGK
variableをどこで設定できるかはドキュメント中の↓から確認できる