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 …[Read more]
These days several kinds and forks of MySQL are widely used, and
while I promised not to write about MySQL bugs till
the end of 2018, I think it makes sense to try to explain basic
details about bug reporting for at least one of vendors that use
JIRA instances as a public bug tracking systems. I work for
MariaDB Corporation and it would be natural for me to write about
MariaDB's JIRA that I use every day.
As a side note, Percona also switched to JIRA some time ago, and many of the JIRA-specific details described below (that are different comparing to good old https://bugs.mysql.com/) apply to Percona bugs …
For some time now, Percona has maintained both the legacy Launchpad bug tracking system and a JIRA bug tracking system for some of the newer products. The time has come to consolidate everything into the JIRA bug tracking system.
Assuming everything goes according to schedule, on December 28, 2017, we will copy all bug reports in Launchpad into the appropriate JIRA projects (with the appropriate issue state). The new JIRA issue will link to the original Launchpad issue, and the new JIRA issue link is added to the original Launchpad issue. Once this is done, we will then turn off editing on the Launchpad projects.
Q&A Which Launchpad projects are affected?
A couple of weeks ago we announced that we were moving from a hosted instance of JIRA to our self hosted instance. The main reason was that we hit 2000 active users in the hosted instance of JIRA and that is the upper limit that it supports. We obviously wanted to allow more people to […]
The MariaDB JIRA instance that currently is in use for project and issue tracking will change. The current instance is hosted in Atlassian’s cloud and it has worked well, but we have hit the maximum user limit of 2000 users. It’s fantastic to see how many of you actually report bugs and other issues in the MariaDB […]
Bug reporting stays open! JIRA is open to anyone. The bug reports are publicly available, even without logging in and as a bonus it will be easier to follow what is going on in the project since you don’t have to jump between several tools to get the complete picture.
All bugs that existed in Launchpad have been migrated to JIRA. To find a bug that was originally reported on Launchpad use the following approaches:
- If you happen to have the original bug id you can search for the bug by typing lp:bugid into the search field in the upper right corner of JIRA. Also, if you have the …
It is not a secret that we’ve been kicking the tires and playing with JIRA for project management. After using it since the beginning of the year most of us like the feel of it and we’ve decided that it makes sense to start using it more.
As you know, the MariaDB project has many fragmented resources. We report bugs in Launchpad. We store our plans in worklog. We’ve never used the Launchpad Blueprint feature for this very reason. We don’t use Launchpad Answers because we have the Knowledgebase.
With this move to hosted JIRA (yes, this is an important link: …[Read more]
I just saw that Atlassian, the provider of the essential community tools like Confluence wiki and JIRA ticket system, updated their wiki on the importance of monitoring the “lifeblood of your organization”.
They even outline the important monitoring tasks you need, and stress that it will help when dealing with their own world class support.
Monitoring involves a number of essential tasks, including those listed below:
- Monitoring log files.
- Checking for HTTP-availability and performance (e.g. by getting the same page every five minutes and displaying the time on a graph).
- Looking at many different parameters such as load, connections, IO, database-trends, and so …