On Fri, 21 Oct 2016 13:16:04 +0200
Josef Skladanka <jskladan@redhat.com> wrote:

> 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.

How far did you end up getting on this?

Tim

_______________________________________________
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-leave@lists.fedoraproject.org