> > 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. _______________________________________________ qa-devel mailing list qa-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
