On Sun, Apr 22, 2018 at 2:23 AM, Stanislav Ochotnicky sochotnicky@redhat.com wrote:
The difference is that PDC rpm-mappings API endpoint was result of two sources:
- 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.
- Ken