maria-developers team mailing list archive
Mailing list archive
Re: Switching on use of components in Jira
On 22.09.2014 17:04, Rasmus Johansson wrote:
I will later today switch on the usage of Components in Jira.
Components are a way of grouping issues inside a project. The idea is
to map every issue in Jira, being it a bug or a new feature to a
component which describes to what area of MariaDB the issue belongs.
For example a bug in Aria would be marked with the component "Storage
Engine - Aria". Currently there are 37 components defined in Jira that
should cover many areas, but I'm sure there are a few missing. There
is one generic to which you can assign issues that doesn't fall into
any other category, called OTHER. I'll include the list of components
here in the end of this email.
* What do you need to do? *
The Component field will be a mandatory field when closing an issue.
Therefore if a component (or several components) haven't been
specified earlier for an issue, you'll have to choose at least one
when closing an issue. The field has autocompletion so if you start
typing for example "Galera" you'll be presented with the alternatives
"Galera", "Galera Arbitrator garbd", and "Galera SST". If you don't
find a suitable component then choose the component called "OTHER".
* What is the benefit of using components? *
It's a way of organizing issues inside a project, so that you easily
can pull out all issues related to a certain area of MariaDB, e.g. if
I wanted to know all bug fixes for replication I would click on the
Replication component and get a list. There is the possibility to set
up automatic assignees based on components and components can be used
in filters and reports throughout Jira.
As one of two first responders to all external MDEV bug reports, I'm not
at all thrilled with the idea of assigning bugs automatically based on
First, reporters are likely to choose wrong components, which means that
bugs will go to wrong people. We cannot expect developers to jump on
every new bug assigned to them in order to analyze and fix the
assignment. At the same time, these bugs will escape our 'unassigned'
queue. It means they can and will be significantly delayed and sometimes
Secondly, even if the reporter guessed correctly, external bugs rarely,
if ever, come totally ready to be processed by developers. Even if they
have perfect description and test cases, they still need to be checked
against different versions, 'fix versions' field should be set, etc. If
it's not done, they are likely to escape our per-release lists.
So, I vote against the automatic assignment.
Taking it off the table, the Components field doesn't make much sense to
me because everything else can be done via Labels. But I assume somebody
actually needs it, and I don't mind filling yet another field if necessary.
Regarding the list of components, I'll repeat again what I've already
tried to communicate a couple times.
The list lacks consistency, which makes it difficult to use.
There is "Data Definition - Procedure", but "Events", "Triggers", "Views".
There are three "DDL" and two "DML" items. If we want be this specific,
all kinds of DDL/DML should be listed, although I don't think it's
necessary -- just "DDL" and "DML" will do, and some important categories
like "Stored procedures", "Triggers" etc. can be listed separately.
There are 8 "Storage Engine - XXX" items. We have more engines, all of
them should be there.
There are some "Platform XXX" items: "Platform Debian", "Platform
FreeBSD", "Platform Power", "Platform Windows". The shouldn't be there,
platforms are not components, that's what labels are for. It would be
reasonable to have, lets say, "Packaging - deb", "Packaging - rpm",
"Packaging - Windows" or something like that, but the current list
doesn't make sense.
There is exactly one "Plugin - XXX" item. We have a number of plugins,
if we want to specify them, all should be there, otherwise none, just
"Plugins" which is already there.
There is "Show Profile" item. We have lots of "SHOW ..." commands, it
makes no sense to single out only one.
- Optimizer (as Roberto already noted)
- Packaging (possibly with subcategories)
- Parser (as Roberto already noted)
- Partitioning (can go as a storage engine, although I personally find
- Prepared statements
- Virtual columns
probably many more. bugs.mysql.com is worth looking at for some ideas,
although it's not perfect either.
I hope this won't be a burden. All feedback is of course welcome.
* Components in the MariaDB Server project in JIRA *
Data Definition - Alter Table
Data Definition - Procedure
Data Definition - Temporary
Data Manipulation - Insert Delayed
Data Manipulation - Subquery
Galera Arbitrator garbd
Plugin - Audit
Storage Engine - Aria
Storage Engine - Cassandra
Storage Engine - Connect
Storage Engine - InnoDB
Storage Engine - OQGRAPH
Storage Engine - Spider
Storage Engine - XtraDB
Storage Enging - TokuDB
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp