[QC-326] Aggregators

[Barthelemy]

No description provided.

[Barthelemy]

Still a bit of work to be done on the doxygen.

[knopers8]

Thank you. I have a lot of small suggestions and questions, but in total, I think it is very good.
I guess that the next step would be to make some common aggregator like WorstFromAll.

I am still a bit puzzled what should happen an aggregator depends on another aggregator. Is it guaranteed that it will be invoked in the same run()?
I am also wondering about circular dependencies among aggregators - this might be a rare case, but perhaps we should check against that to warn a user. Maybe not in this iteration, but later.

[Barthelemy]

Thank you. I have a lot of small suggestions and questions, but in total, I think it is very good.
I guess that the next step would be to make some common aggregator like WorstFromAll.

Great review, thank you !
I am addressing the suggestions step by step.

Yes, I have create https://alice.its.cern.ch/jira/browse/QC-488. I have assigned it to you for the time being with the idea that it might be beneficial that someone else tries out the aggregators. However, I can take it back if needed.

I am still a bit puzzled what should happen an aggregator depends on another aggregator. Is it guaranteed that it will be invoked in the same run()?

No, it is not guaranteed. If they are defined in a non optimal order, then you could have to wait for the next call to run(). It means that in this case, the aggregator will have to work with the quality of the last cycle, i.e. that it there will be a kind of delay. We could improve it by creating a tree and making them run in the correct order. I would postpone that for a future improvement but I will add a comment in the documentation. https://alice.its.cern.ch/jira/browse/QC-489

I am also wondering about circular dependencies among aggregators - this might be a rare case, but perhaps we should check against that to warn a user. Maybe not in this iteration, but later.

I considered circular dependencies and it should not be a disaster for the policy OnAny because the aggregators have access to the quality of the previous cycle in the worst case (we maintain the container). For "OnAll" it could be a problem because it will never trigger. I propose to treat it in QC-489 as well.

[knopers8]

Yes, it would be good if I played with it as well, the ticket can stay with me.
Agreed for the other issues as well.

[Barthelemy]

I think that I fixed most of the things. There are 3 open items that I let you have a look at on Monday.