Sunday, January 13, 2019

Understanding Status of MariaDB Server JIRA Issues

In my previous blog post on MariaDB's JIRA for MySQL users who are familiar with MySQL bugs database (but may be new to JIRA) I've presented some details about statuses that JIRA issues may have. There is no one to one correspondence with MySQL bug's statuses that I once described in details here. In case of MariaDB Server bugs ("JIRA issues") one may have to check not only "Status" field, but also "Resolution" filed and even "Labels" field to quickly understand what is the real status and what MariaDB engineers decided or are waiting for. So, I think some additional clarifications may help MySQL users who check or report MariaDB bugs as well.

Let me present details of this statuses correspondence in a simple table, where the first column contains MySQL's bug status, while 3 other columns contain the content of corresponding MariaDB Server JIRA issue's fields, "Status", "Resolution" and "Labels". There is also "Comment" column with some explanation on what else is usually done in JIRA issue when it gets this set of values defining its status or what this may mean in MySQL bugs database etc. Most important MySQL bug statuses are taken from this my post (there are more of them, but others are rarely used, especially when real work on bugs was moved into internal bugs database by Oracle, or were removed since that post as it happened to "To be fixed later").

MySQL Bug StatusMariaDB JIRA StatusMariaDB JIRA ResolutionMariaDB JIRA LabelComment
OpenOPENUnresolvedTypical status for just reported bug
ClosedCLOSEDFixedYou should see list of versions that got the fix in the Fix Version/s field
DuplicateCLOSEDDuplicateSo, in MariaDB it's "closed as a duplicate"
AnalyzingOPENUnresolvedUsually bug is assigned when some engineer is working on it, including analysis stage
VerifiedCONFIRMEDUnresolvedCONFIRMED bugs are usually assigned in JIRA while in MySQL "Verified" bugs are usually unassigned
Won't fixCLOSEDWon't FixUsually remains assigned
Can't repeatCLOSEDCannot reproduceUnlike in MySQL, usually means that both engineer and bug reporter are not able to reproduce this
No FeedbackCLOSEDIncompleteneed_feedbackAs in MySQL, bug should stay with "need_feedback" label for some time before it's closed as incomplete
Need FeedbackOPENUnresolvedneed_feedbackUsually in the last comment in the bug you can find out what kind of feedback is required. No automatic setting to "No Feedback" in 30 days
Not a BugCLOSEDNot a Bug 
UnsupportedCLOSEDWon't FixThere is no special "Unsupported" status in MariaDB. Most likely when there is a reason NOT to fix it's stated in the comment.

In the table above you can click on some links to see the list of MariaDB bugs with the status discussed in the table row. This is how I am going to use this post from now on, as a quick search starting point :) It will also be mentioned on one of slides of my upcoming FOSDEM 2019 talk.


  1. One thing not mentioned here is that it is not currently possible to provide non-public information as part of a bug report. This is made slightly more complicated by the fact, as you indicate, that the number of different groups of people who may have access to the bug may not simply be "MariaDB staff" and the fact that there is a difference between and as separate entities.

    It can be generally handy to be able to provide private comments, or more specific internal information to help diagnose the cause of a bug, or provide context, and to share this with those that "handle" the bug report, but not want to make that information visible to the wider public.

    Having such a facility would be nice as long as it is clear who will be able to see that "private information".

  2. Nice reference, thank you. You work in MariaDB and worked in MySQL team, so it would be interesting to hear from you some comments - if those systems are equivalent and, if not, which one works best for quality.

    1. Starting from MariaDB 5.5.x they become more and more different in features and development focus. MariaDB has more storage engines, of different maturity and quality, and some features that will probably never exist in MySQL (like PL/SQL support or system-versioned tables in 10.3).

      I'd say that, in general, common features should get way more QA in MariaDB comparing to Oracle's MySQL and should be of higher quality. Same is true for Percona Server vs Oracle MySQL of the same major version, by the way.

      As for unique engines and features, I do not have any good metrics to compare. Some engines are surely more buggy and less tested than MySQL in general.

      From experience, MariaDB 10.1 and 10.2 are mature (same as MySQL 5.6 or 5.7, for example), I rarely see really bad unique problems. More features means more problems, as one can see with MySQL 8 as well.

      That said, I do not follow MariaDB bugs as close as MySQL ones. I report and follow bugs my support customers hit mostly in case of MariaDB. With MySQL I check new bugs reported every day. This is my hobby, one of things I do for fun and main topic of this blog.