On Thu, Jul 17, 2014 at 3:27 AM, Vishvananda Ishaya <vishvana...@gmail.com> wrote: > On Jul 16, 2014, at 8:28 AM, Daniel P. Berrange <berra...@redhat.com> wrote:> >> On Wed, Jul 16, 2014 at 08:12:47AM -0700, Clark Boylan wrote: >> >>> I am worried that we would just regress to the current process because >>> we have tried something similar to this previously and were forced to >>> regress to the current process. >> >> IMHO the longer we wait between updating the gate to new versions >> the bigger the problems we create for ourselves. eg we were switching >> from 0.9.8 released Dec 2011, to 1.1.1 released Jun 2013, so we >> were exposed to over 1 + 1/2 years worth of code churn in a single >> event. The fact that we only hit a couple of bugs in that, is actually >> remarkable given the amount of feature development that had gone into >> libvirt in that time. If we had been tracking each intervening libvirt >> release I expect the majority of updates would have had no ill effect >> on us at all. For the couple of releases where there was a problem we >> would not be forced to rollback to a version years older again, we'd >> just drop back to the previous release at most 1 month older. > > This is a really good point. As someone who has to deal with packaging > issues constantly, it is odd to me that libvirt is one of the few places > where we depend on upstream packaging. We constantly pull in new python > dependencies from pypi that are not packaged in ubuntu. If we had to > wait for packaging before merging the whole system would grind to a halt. > > I think we should be updating our libvirt version more frequently vy > installing from source or our own ppa instead of waiting for the ubuntu > team to package it.
I agree with Vish here, although I do recognise its a bunch of work for someone. One of the reasons we experienced bugs in the gate is that we jumped 18 months in libvirt versions in a single leap. If we had flexibility of packaging, we could have stepped through each major version along the way, and that would have helped us identify problems in a more controlled manner. Michael -- Rackspace Australia _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
