I think we miss a VOTE from Jenkins, the vote from Jenkins should be taken as highest priority in each release. This kind of regression should be easily identified in Jenkins(If we have a regression test for each environment).
> -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Wednesday, June 05, 2013 9:03 AM > To: dev@cloudstack.apache.org > Subject: KVM development, libvirt > > It looks like a bug was probably introduced into 4.1, where stock Ubuntu > 12.04 doesn't support part of the libvirt xml format for system vms. I feel > bad > that it got in there, but I think it highlights an issue that needs to be > addressed within our development. Libvirt versioning is somewhat of a > moving target. Features are introduced rapidly, and versions vary quite a bit > between distributions and releases of those distributions. Despite this, > we've largely ignored what libvirt we are targeting, assuming "whatever is on > the distribution". There is the occasional discussion about this or that being > available in libvirt x.x.x during the development cycle, but when it comes to > qualifying the release we don't pay attention to it. > We should. Looking at the vote for 4.1.0, several people call out which > OS/distribution they use, but I'd like to see the libvirt version as well. > > Here are some initial thoughts, please add to these if you can: > > 1) When voting for a release, should we require a minimum number of votes > FOR EACH supported OS? Meaning that we require positive test results from > every OS listed as supported? In retrospect this seems like a no-brainer, > however it may change the bylaws. > > > 2) Do we want to pull libvirt out as a standalone dependency? Meaning that > we code to a specific version and make that more visible. This could be a > "least common denominator" type thing where we pick the lowest version > from all supported OSes, or it could be independent of distribution, > whatever we decide, but we would make an effort to call out the version and > treat it independently of OS. > > 3) I can think of a few things we could do in packaging to help catch > versioning, but I'm not sure they would entirely address the issues.
