The scanning for purely.buildsys.tag seems a bit too open to me.
Maybe we want to explicitly check that it's the exact correct topic, since we base signing decisions off of it?

I like your optimism! I'd say this is really a v1.0.0, but this works for now :).

I'd say you definitely earn it to be in here, but I understand your reluctance if you don't want to :).

Really nice, thank you so much for this!
The only comment I'd like resolved is the topic matching to be more specific, but other than that this looks great to me!

Thanks for the review. So you'd prefer checking org.fedoraproject.prod.buildsys.tag? Rather than checking more precisely in the code, we can make the bindings more specific in the configuration file. (see the [[bindings]] section).

That works for me.
Just trying to avoid we trigger on org.fedoraproject.prod.bodhi.buildsys.tag :).

Hello - does fedora-messaging here work with amqp 1.0+? I asked around and heard that it doesn't. If true, that would break our downstream instance from tracking upstream here.

@puiterwijk : If the bindings are set as in the current exemple file: "org.fedoraproject.*.buildsys.tag", then it should not be a problem, because the star character does not match dots.

@ralph : Yeah I've seen this question asked in other projects, fedora-messaging is only a thin wrapper around the Pika library, which is designed to work with AMQP 0-9-1 and not AMQP 1.0+ (which is a totally different protocol if I understand correctly).

If you are either using fedmsg or AMQP 1.0+ in your infrastructure, I'm not sure what the best course of action would be but maybe having a bridge component running somewhere would be easier than adding multiple protocol support to all bus-enabled apps?

@jcline, any opinion on that? It seems to be a frequent question, maybe we could add it to our docs?

Hello - does fedora-messaging here work with amqp 1.0+? I asked around and heard that it doesn't. If true, that would break our downstream instance from tracking upstream here.

As @abompard said, it's just sugar on Pika. I met with some factory 2 folks months and months ago about implementing the same API backed with a AMQP 1.0 client so internal could keep on using what Fedora is using, but as far as I know no one was committed to the work so it never happened.

I do think there should be something on the home page of the docs that mentions it's just wrapping Pika, an AMQP 0.9.1 client.

edit: they filed a tracker ticket https://github.com/fedora-infra/fedora-messaging/issues/148

The plan for downstream seems to be to keep the fedmsg-enabled version from EPEL 7 running until they move off fedmsg themselves.
I think that nothing else blocks this PR, correct?

@abompard - correct!
Thank you very much for this patch!