After some thinking about bug 989946 I think the elephant in the room is
the activation of plugins. This is done using heuristics which works
reasonably well in most cases. However, if these heuristics doesn't
work, it puts the user in a awkward position. In the 999846 case, we run
java tests on a non-java package, and user has really no way to disable
this, or even understand the problem.
I have pushed a feature branch plugin-fixes. Basically, it does two things:
- Adds some feedback about enabled and disabled plugins.
- Adds a new --plugins option which can be used to enable/disable
plugins, overriding the heuristics.
What I try to do is to make the whole "what plugins should be run" mess
visible and configurable. In the 989946 scenario, user could the use
--plugins to disable the bogus java tests. This means a new option, we
don't want that. But perhaps it can be justified in this case (?)
Depending on input, I plan to merge this to devel eventually.
Notes:
- Here is no feedback on why certain plugins are run (Stan's proposal).
It certainly be added
- I actually still don't think java tests should be run just because the
unpatched sources contains a .java file. Too aggressive IMHO. But this
should be resolved in the bug context.
--alec
Show replies by date