On Sun, Apr 22, 2018 at 2:23 AM, Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx> 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 _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
