On Wed, 20 May 2015 09:02:49 -0400 (EDT) Martin Krizek <[email protected]> wrote:
<snip> > > > 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 notify the maintainer of the package via fedmsg about > > > the result). If we target users, we'd have to have some logic to > > > limit rate of fedmsgs ourselves but that would mean hiding some > > > of the results (although duplicates) from the world. > > > > I'd like to see us do the deduplication in resultsdb (assuming > > that's where the fedmsg emission will be happening). I think that > > we already have a table for items and I don't think that keeping > > track of "is_emitted" and the last state emitted (so we can track > > changes in state) would be too bad. Then again, I'm not the one > > working in the code and I could be wrong :) > > > > Can you think of a use case when someone would want to receive all > results including duplicates? For the per-repo checks that we're changing to emulate the behavior of per-build/update checks? No, I can't think of a reason why anyone other than us would be interested in getting all that data. Tim
pgpMdf0ZhVDhH.pgp
Description: OpenPGP digital signature
_______________________________________________ qa-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/qa-devel
