On Sun, Apr 22, 2018 at 2:23 AM, Stanislav Ochotnicky
The difference is that PDC rpm-mappings API endpoint was result of
* Manual per-rpm mappings (overrides) - this is sort of suitable if you
have a product with just a couple source packages so it's manageable
this way (i.e Ceph case)
* Results of compose metadata import - this is what Fedora/RHEL uses
because several thousands of source packages are not manageable
one-by-one by humans manually.
You could still make a system that would create "PRs" for the generated
files for second case, but then querying the current state will still be
a bit tricky. I guess...
Yeah, the fact that we have (at least) two different input and storage
methods there is a lot of complexity. I'm not sure that's a good
design in 2018.
Regardless, you're right, I'm envisioning that we'd have a tool to
generate the data commits and PRs (or just commit + push directly).
PDC had included its own rudimentary form of version control for
auditing and message bus integration. Git's experience is much richer.