> > We talked with Martin about this in length some time ago, and I
> > raised the question of different consumers. I see two groups here -
> > machines and humans. If I understand you correctly, what you propose
> > up there is to hardcode the system to fit human preferences. If I
> > misunderstoo
nstant re-running. But it seems reasonable to
> assume that it will be a small minority in the overall task pool.
>
> >
> > For the majority of tasks, I see the process as being similar to:
> >
> > 1. trigger task $x for $y
> > 2. run task $x with $y as i
On Wed, 20 May 2015 09:02:49 -0400 (EDT)
Martin Krizek wrote:
> > > So if we target systems we'd just send all results in fedmsgs and
> > > let the systems consume them and do whatever they want to do with
> > > them (e.g. bodhi can squash all the tasks relevant to specific
> > > update and not
t;
> For the majority of tasks, I see the process as being similar to:
>
> 1. trigger task $x for $y
> 2. run task $x with $y as input
> 3. report result for $x($y)
>
> With this, we'd be running $x for each $y and the reporting would only
> happen for each uni
- Original Message -
> From: "Tim Flink"
> To: qa-devel@lists.fedoraproject.org
> Sent: Friday, May 15, 2015 1:14:56 AM
> Subject: Re: Fedmsg Emitting
>
> On Thu, 14 May 2015 20:02:29 +0200
> Martin Krizek wrote:
>
> > Before we start sending fed
y of tasks, I see the process as being similar to:
1. trigger task $x for $y
2. run task $x with $y as input
3. report result for $x($y)
With this, we'd be running $x for each $y and the reporting would only
happen for each unique ($x, $y) assuming that something wasn't
reschedu
Before we start sending fedmsgs we need to discuss a few things. We don't
have to find solutions to all these problems, just keep them in mind
when designing the solution we're going to start with:
1. How often do we send fedmsg
a) per-task
b) per-update
c) per-build
a) and b): we can list affect
