[Maria-developers] Switching on use of components in Jira
Hello all, 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. I hope this won't be a burden. All feedback is of course welcome. BR, Rasmus * 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 Dynamic Columns Events Full-text Search Galera Galera Arbitrator garbd Galera SST GIS Locale Settings OTHER Platform Debian Platform FreeBSD Platform Power Platform Windows Plugin - Audit Plugins Query Cache Replication Show Profile sql_error_log SSL Storage Engine - Aria Storage Engine - Cassandra Storage Engine - Connect Storage Engine - InnoDB Storage Engine - OQGRAPH Storage Engine - Spider Storage Engine - XtraDB Storage Enging - TokuDB Time zones Triggers Views XML Functions
please include a new compenent Optimizer/Parser 2014-09-22 10:04 GMT-03:00 Rasmus Johansson <rasmus@mariadb.com>:
Hello all,
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.
I hope this won't be a burden. All feedback is of course welcome.
BR, Rasmus
* 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 Dynamic Columns Events Full-text Search Galera Galera Arbitrator garbd Galera SST GIS Locale Settings OTHER Platform Debian Platform FreeBSD Platform Power Platform Windows Plugin - Audit Plugins Query Cache Replication Show Profile sql_error_log SSL Storage Engine - Aria Storage Engine - Cassandra Storage Engine - Connect Storage Engine - InnoDB Storage Engine - OQGRAPH Storage Engine - Spider Storage Engine - XtraDB Storage Enging - TokuDB Time zones Triggers Views XML Functions
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Roberto Spadim SPAEmpresarial Eng. Automação e Controle
a example of MDEV using Optimizer: https://mariadb.atlassian.net/browse/MDEV-6696 2014-09-22 14:51 GMT-03:00 Roberto Spadim <roberto@spadim.com.br>:
please include a new compenent Optimizer/Parser
2014-09-22 10:04 GMT-03:00 Rasmus Johansson <rasmus@mariadb.com>:
Hello all,
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.
I hope this won't be a burden. All feedback is of course welcome.
BR, Rasmus
* 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 Dynamic Columns Events Full-text Search Galera Galera Arbitrator garbd Galera SST GIS Locale Settings OTHER Platform Debian Platform FreeBSD Platform Power Platform Windows Plugin - Audit Plugins Query Cache Replication Show Profile sql_error_log SSL Storage Engine - Aria Storage Engine - Cassandra Storage Engine - Connect Storage Engine - InnoDB Storage Engine - OQGRAPH Storage Engine - Spider Storage Engine - XtraDB Storage Enging - TokuDB Time zones Triggers Views XML Functions
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Roberto Spadim SPAEmpresarial Eng. Automação e Controle
-- Roberto Spadim SPAEmpresarial Eng. Automação e Controle
Hi Rasmus, On 22.09.2014 17:04, Rasmus Johansson wrote:
Hello all,
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 components. 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 totally missed/forgotten. 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. Missing categories: - Buildbot - Compiling - Documentation - Locking - Logging - 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 it confusing) - Prepared statements - Tests - Virtual columns probably many more. bugs.mysql.com is worth looking at for some ideas, although it's not perfect either. Regards, Elena
I hope this won't be a burden. All feedback is of course welcome.
BR, Rasmus
* 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 Dynamic Columns Events Full-text Search Galera Galera Arbitrator garbd Galera SST GIS Locale Settings OTHER Platform Debian Platform FreeBSD Platform Power Platform Windows Plugin - Audit Plugins Query Cache Replication Show Profile sql_error_log SSL Storage Engine - Aria Storage Engine - Cassandra Storage Engine - Connect Storage Engine - InnoDB Storage Engine - OQGRAPH Storage Engine - Spider Storage Engine - XtraDB Storage Enging - TokuDB Time zones Triggers Views XML Functions
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Hi Elena, On Mon, Sep 22, 2014 at 11:32 PM, Elena Stepanova <elenst@montyprogram.com> wrote: <cut>
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 components.
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 totally missed/forgotten.
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.
I think you made some fair points above for not making use of automatic assignments. I
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.
The "problem" with labels is that it doesn't restrict to use only a specific set of labels. It's easy to end up with a bunch of labels that all mean the same but the label names are just a little bit different.
Regarding the list of components, I'll repeat again what I've already tried to communicate a couple times.
Sorry that I have missed and not reacted on your feedback earlier!
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.
Yes and no. I need to dig up the logic why we for example back in the days chose to follow the usage of specific features in the Feedback plugin, see http://mariadb.org/feedback_plugin/stats/features/ .
There are 8 "Storage Engine - XXX" items. We have more engines, all of them should be there.
Yes, all of them should be there. I'll add.
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.
You're probably right on this one as well since we don't want to end up with 50+ platform components. Also the Environment -field addresses the platform aspect.
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.
Yes, plugins is probably too generic and the storage engines could even fall under that. Need to think about this.
There is "Show Profile" item. We have lots of "SHOW ..." commands, it makes no sense to single out only one.
Missing categories: - Buildbot - Compiling - Documentation - Locking - Logging - 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 it confusing) - Prepared statements - Tests - Virtual columns
probably many more. bugs.mysql.com is worth looking at for some ideas, although it's not perfect either.
I added the ones reported by Roberto already and I'll add the others you have in the list. Thanks for very good feedback! I think this will be an iterative process for a while, but eventually there will probably be a set of components that covers most things. Rasmus
participants (3)
-
Elena Stepanova -
Rasmus Johansson -
Roberto Spadim