> Proposal looks good to me, I don't have any strong objections. > 1. If you don't like blame: UNIVERSE, why not use blame: TESTBENCH? > 2. I think that having enum values in details in crash structure would be > better, but I don't have strong opinion either way.
For consistency checking, yes. But it's somewhat inflexible. If the need arises, I imagine the detail string can be in json format (or semicolon-separated keyvals or something) and we can store several useful properties in there, not just one. E.g. not only that Koji call failed, but what was its HTTP error code. Or not that dnf install failed, but also whether it was the infamous "no more mirror to try" error or a dependency error. I don't want to misuse that to store loads of data, but this could be useful to track specific issues we have hard times to track currently (e.g. our still existing depcheck issue, that happens only rarely and it's difficult for us to get a list of tasks affected by it). With this, we could add a flag "this is related to problem XYZ that we're trying to solve".
_______________________________________________ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
