On 2014-08-08 09:06:29 -0400 (-0400), Russell Bryant wrote: [...] > We've seen several times that building and maintaining 3rd party > CI is a *lot* of work.
Building and maintaining *any* CI is a *lot* of work, not the least of which is the official OpenStack project CI (I believe Monty mentioned in #openstack-infra last night that our CI is about twice the size of Travis-CI now, not sure what metric he's comparing there though). > Like you said in , doing this in infra's CI would be ideal. I > think 3rd party should be reserved for when running it in the > project's infrastructure is not an option for some reason > (requires proprietary hw or sw, for example). Add to the "not an option for some reason" list, software which is not easily obtainable through typical installation channels (PyPI, Linux distro-managed package repositories for their LTS/server releases, et cetera) or which requires gyrations which destabilize or significantly complicate maintenance of the overall system as well as reproducibility for developers. It may be possible to work around some of these concerns via access from multiple locations coupled with heavy caching, but adding that in for a one-off source is hard to justify the additional complexity too. > I wonder if the job could be as simple as one with an added step > in the config to install latest libvirt from source. Dan, do you > think someone could add a libvirt-current.tar.gz to > http://libvirt.org/sources/ ? Using the latest release seems > better than master from git. [...] Would getting it into EPEL for CentOS 7 or UCA for Ubuntu 14.04 LTS hopefully be an option? -- Jeremy Stanley _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev