Klever

Why is this necessary? For me it seems very good to see the total number of problems as it is shown now. For instance, let's assume that one "bad" module breaks verification of 5 modules since it is added to corresponding verification objects, and there is another "bad" module that breaks verification of the only module. It would be nice to see all 5 unknowns in the first case to understand better than a corresponding issue should be likely fixed first.

Ilja Zakharov wrote:

I agree that the total number of unknowns is of interest. But at analyzing results of multimodule verification and comparing them with existing ones there is a difficulty of distinguishing actual problems of mutlimodule verification from problems caused by an insertion of a bad module in different verification objects. Currently, I have no good proposal how to deal with it.

In my opinion, insertion of a "bad" module is exactly a problem of multimodule verification. And the only thing to be done, I think, is to specify better somehow that some problems have the same reason.

Actually this isn't an intrinsic property of multimodule verification. Similar issues exist for all components, e.g. you tried to investigate reasons of timeouts, some bugs in Weaver can steam from issues in EMG, etc. "Simple" regular expressions can't always help. So, some additional things are required.

I suppose you will think more about this and suggest some nice improvement in unknown reports representation that will allow to identify failure reasons in a more advanced way in comparison with regular expressions. Don't forget about a timeouts classification and either relate the given issue with the corresponding one if it exists, or open a new one, or make this one more generic.