maria-developers team mailing list archive

[Rasmus Johansson <rasmus@xxxxxxxxxxx>]

Hi Elena,

On Mon, Sep 22, 2014 at 11:32 PM, Elena Stepanova
<elenst@xxxxxxxxxxxxxxxx> 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