How to create a useful MySQL bug report
...and make sure it's properly processed
- Track: MySQL, MariaDB and Friends devroom
- Room: UA2.118 (Henriot)
- Day: Saturday
- Start: 16:10
- End: 16:30
This session is for those MySQL DBAs and users who found some wrong, erratic, undocumented behavior while working with MySQL or MariaDB, got it crashed or failed in a way they consider totally wrong. We discuss what details to collect and provide, what tools to use and what steps to perform to create a public bug report that is processed (and, hopefully, fixed) fast. Possible efficient ways to escalate bugs that do not get proper attention are also presented.
This session is for those MySQL DBAs and users who found some wrong, erratic, undocumented behavior while working with MySQL or MariaDB, got it crashed or failed in a way they consider totally wrong. We discuss what details to collect and provide, what tools to use and what steps to perform to create a bug report that is processed (and, hopefully, fixed) fast.
We discuss current life cycles of MySQL and MariaDB bugs, details of practical bug trackers usage, approaches to "security" bugs and escalation procedures, formal and informal - everything to get a real MySQL bug processed, properly fixed and documented. All this based on my personal experience of 14+ years of bugs reporting, processing and prioritizing in MySQL, Sun, Oracle, Percona and MariaDB Corporation.
Speakers
Valerii Kravchuk |
Attachments
Links
- Basic structure would be the same as on these slides
- Initial blog post on the topic
- On recently added severity levels for MySQL bugs
- On reporting MySQL bugs upstream for support providers
- On reporting MySQL bugs in public for Oracle customers
- Slides for this talk at SlideShare
- http://
- Video recording (WebM/VP9)
- Video recording (mp4)
- Submit feedback