Jeremy Cline

Cool. To expand upon this a little (and maybe this should be an entirely separate issue since schemas are just a part of it), the current interface is causing me...

I've done some investigation about how this API might get implemented. It was satisfying to see the [pyzmq documentation recommend the approach I had in mind](https://pyzmq.readthedocs.io/en/latest/serialization.html#using-your-own-serialization), but unfortunately there's a...

I guess what I'm driving at is what does fedmsg want to _be_. Does it aim to be a high-level messaging library very much like [kombu](https://kombu.readthedocs.io/en/latest/introduction.html)? Does it want to...

I don't know anything about the docker registry, but it sounds like there would be two approaches here: 1) write some Go code to implement a Sink that emits ZeroMQ...

We've [proposed](https://lists.fedoraproject.org/archives/list/[email protected]/thread/HLOYNCI4X6ELF76HP54UBMMNL4FPDBQW/) moving to AMQP for Fedora and dropping support for fedmsg. The publish endpoint will be preserved and will likely remain ZeroMQ, but as part of this proposed migration...

Ideally yes, fedmsg would be retired, but I don't think fedmsg offers any value over the pyzmq bindings it uses to send messages. Publishing an (unsigned) message in the same...

It'll be backwards compatible and people will have plenty of time to migrate

That's a good point. Perhaps a better scheme would be: If a file is specified on the CLI, use that (and only that) configuration. Otherwise, load all configuration from /etc/fedmsg/conf.d/....

I don't object to this, but sadly it will likely require breaking APIs. The reason is fedmsg requires ``fedmsg.core`` in ``fedmsg/__init__.py`` which in turns requires ``zmq``: ``` Python 3.6.3 (default,...

The plan is to kill fedmsg and fedmsg[meta] completely and replace it with https://github.com/fedora-infra/fedora-messaging, so that's certainly possible. The idea is to replace fedmsg[meta] with per-project Python packages that contain...