Sergey "Shnatsel" Davidoff

AFAIK the DDS format is outside the expertise of all of the current maintainers, and the in-tree code was mostly inherited and poorly maintained. I am excited to see it...

> So the basic idea is to invert the dependency. Instead of image depending on dds, image will be completely independent with dds depending on image and its plugin API....

I've been wondering, is `image-extras` even needed now that the plugin interface exists? There doesn't seem to be a whole lot of benefits to bundling all these different formats together...

**TL;DR:** this is a worthwhile change, but I'd like to see it on the framework level (i.e. in `abscissa`) rather than fix up every user individually. I've compared this against...

More specifically, the guide states that subcomponents should be used in case of a "Multi-Product Solution" rather than a "Multi-Module Product". You can work around this today with `--describe=binaries`, but...

Having both `new()` and `FromStr` sounds good to me. I'd be happy to merge a PR with this change.

I think a better idea is to just disable the `resolve*` features that pull in `hyper`. We really don't want to pull in the entirety of reqwest, hyper and tokio...

The `jsonschema` crate pulls in a lot of dependencies and shouldn't be a runtime dependency at all. We should turn it into a dev-dependency. There is now an issue about...

Turning `jsonschema` into an optional feature is a breaking change if someone was using the crate with `default-features = false`, but I don't think anyone has been doing that on...

Since this appears to have stalled, I started pruning the dependency tree myself. See #744 and #746