So, after a long discussion, we arrived to this solution. We will clearly split up the "who to notify" part, and "should we re-schedule" part of the proposal. The party to notify will be stored in the `notify` field, with `taskotron, task, unknown` options. Initially any crashes in `shell` or `python` directive, during formula parsing, and when installing the packages specified in the formula's environment will be sent to task maintainers, every other crash to taskotron maintainer. That covers what I initially wanted from the multiple crashed states.
On top of that, we feel that having an information on "what went wrong" is important, and we'd like to have as much detail as possible, but on the other hand we don't want the re-scheduling logic to be too complicated. We agreed on using a `cause` field, with `minion, task, network, libtaskotron, unknown` options, and storing any other details in a key-value store. We will likely just re-schedule any crashed task anyway, at the beginning, but this allows us to hoard some data, and make more informed decision later on. On top of that, the `fatal` flag can be set, to say that it is not necessary to reschedule, as the crash is unlikely to be fixed by that. This allows us to keep the re-scheduling logic rather simple, and most imporantly decoupled from the parts that just report what went wrong.
_______________________________________________ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
