> check - FAILED
> subcheck1 - PASSED
> subcheck2 - PASSED
> subcheck3 - FAILED
> subcheck4 - PASSED
>
> !IMPORTANT: ResultsDB will not be responsible for computing the
> result value for an "upper level" Result from the subchecks - this is
> the check's (check developer's) responsibility.
Are we going to require an overall status for the grouped subchecks?
Unless some part of our code (resultsdb) requires it, I'd not mandate it. Some checks
(like rpmgrill) might be composed of smaller checks, and it might not make much sense to
try to create an overall result out of that (unless it is used for gating, or similar).
> NOTE: Although we do not encourage to store the results to the
finest
> granularity "just because" (e.g. individual results of a unittest
> testsuite), we leave it to the check-developer's judgement. If there
> is a usecase for it, let them do it, we don't care, as long as the DB
> is not extremely overloaded.
To nitpick a bit, I had to read the first part of that a couple times
before understanding.
Maybe something like:
Although the check developer has the final say over the granularity of
results stored, we do not suggest storing results simply for the sake
of having them
Was my version too long? :-) Because I think we should include some explanation why they
would want or not want store and emit detailed results. And some examples are the best way
for guiding people. That's what I tried to provide in my previous email.