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").
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.
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 Status | MariaDB JIRA Status | MariaDB JIRA Resolution | MariaDB JIRA Label | Comment |
| Open | OPEN | Unresolved | Typical status for just reported bug | |
| Closed | CLOSED | Fixed | You should see list of versions that got the fix in the Fix Version/s field | |
| Duplicate | CLOSED | Duplicate | So, in MariaDB it's "closed as a duplicate" | |
| Analyzing | OPEN | Unresolved | Usually bug is assigned when some engineer is working on it, including analysis stage | |
| Verified | CONFIRMED | Unresolved | CONFIRMED bugs are usually assigned in JIRA while in MySQL "Verified" bugs are usually unassigned | |
| Won't fix | CLOSED | Won't Fix | Usually remains assigned | |
| Can't repeat | CLOSED | Cannot reproduce | Unlike in MySQL, usually means that both engineer and bug reporter are not able to reproduce this | |
| No Feedback | CLOSED | Incomplete | need_feedback | As in MySQL, bug should stay with "need_feedback" label for some time before it's closed as incomplete |
| Need Feedback | OPEN | Unresolved | need_feedback | Usually 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 Bug | CLOSED | Not a Bug | ||
| Unsupported | CLOSED | Won't Fix | There 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.