maria-developers team mailing list archive
Mailing list archive
Re: Switching on use of components in Jira
On Mon, Sep 22, 2014 at 11:32 PM, Elena Stepanova
> 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 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
> 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
> - 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.