So far we've been treating fedmod as an experimental tool to help us get to the Fedora 27 Modular Server release, but with that deferred until F28, and the release strategy changing to permit build and runtime dependencies on the full non-modular package set, it's time to look seriously at the capabilities we want in a fedmod 1.0 release that starts offering full CLI backwards compatibility assurances.

Workflow requirements:

• mandatory pre-merge CI (Do we need to move to GitHub for this, or can we get something reasonable working with Pagure?): https://pagure.io/modularity/fedmod/issue/24
• submit fedmod for review as a proper Fedora package, rather than relying solely on COPR builds

Functional requirements:

• support named data sets: https://pagure.io/modularity/fedmod/issue/4
• support selection of the "package repos" and the "module repos" when running fetch-metadata
• stop relying on dnf metadata on the system running fedmod: https://pagure.io/modularity/fedmod/issue/28
• update the module generator to use the hybrid model and not inject every non-modular build and runtime dependency into the generator modulemd

Workflow "Nice to haves":

• automated post-merge docs publication (Do we need to move to GitHub for working ReadTheDocs integration, or can we get that working with Pagure?)

Functional "Nice to haves":

• support explanatory comments in the generated modulemd files by switching away from modulemd.dump for formatting: https://pagure.io/modularity/fedmod/issue/8