> are you doing that manually

Yes, completely manual

> I'm not sure oVirt's own infra would be the best place, because Patternfly is not strictly an oVirt project.

True. However, we've talked about renaming the rpm to 'ovirt-patternflyX' to reflect the fact that it's only used by us. In that case, it might make sense to move it to our infra.

are you doing that manually, or do you have some automation built around it?

I'm not sure oVirt's own infra would be the best place, because Patternfly is not strictly an oVirt project.
Perhaps make travis run the build in Copr, and then take the result and push it to GitHub's artifact storage?
Another possibility is to use BinTray

We might eventually mirror this in oVirt infra to make CI resilient to changes there (see )

I maintain patternfly on copr. No one else uses it, so we can move it anywhere that makes sense.

is it possible to get pattenfly from other place than Copr?
We're seeing more and more failures on repos hosted by copr, we might want to find a more stable repo on other services.
Who is building/maintaining those builds?

Which projects are coming from Copr? Maybe they would like us to host their artifacts on resources.ovirt.org (And would happily make their CI systems update it with new builds)? Or perhaps they would push into Fedora? or EPEL? or CentOS? Or even just GitHub?

I guess if we setup out own mirrors for stuff it will solve our problems, but a project that only releases on copr has a problem IMO....

I do not think there are mirrors for COPR as its content changes too often and isn't used by a lot of people.

This won't prevent it from failing in the future.
is it possible to add more mirrors here as you did for std ci?

currently I don't see any problem with the [1] repository
1. The old jobs from 2/12/2016 that were failed, do not exist
2. The latest jobs successfully passed

[1] - http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-7-x86_64/

can we do something about it? maybe add more mirrors to copr?