On Fri, Apr 06, 2018 at 12:12:31PM -0500, Matt Riedemann wrote: > On 4/6/2018 12:07 PM, Kashyap Chamarthy wrote: > > FWIW, I'd suggest so, if it's not too much maintenance. It'll just > > spare you additional bug reports in that area, and the overall default > > experience when dealing with CPU models would be relatively much better. > > (Another way to look at it is, multiple other "conservative" long-term > > stable distributions also provide libvirt 3.2.0 and QEMU 2.9.0, so that > > should give you confidence.) > > > > Again, I don't want to push too hard on this. If that'll be messy from > > a package maintainance POV for you / Debian maintainers, then we could > > settle with whatever is in 'Stretch'. > > Keep in mind that Kashyap has a tendency to want the latest and greatest of > libvirt and qemu at all times for all of those delicious bug fixes.
Keep in mind that Matt has a tendency to sometimes unfairly over-simplify others views ;-). More seriously, c'mon Matt; I went out of my way to spend time learning about Debian's packaging structure and trying to get the details right by talking to folks on #debian-backports. And as you may have seen, I marked the patch[*] as "RFC", and repeatedly said that I'm working on an agreeable lowest common denominator. > But we also know that new code also brings new not-yet-fixed bugs. Yep, of course. > Keep in mind the big picture here, we're talking about bumping from > minimum required (in Rocky) libvirt 1.3.1 to at least 3.0.0 (in Stein) > and qemu 2.5.0 to at least 2.8.0, so I think that's already covering > some good ground. Let's not get greedy. :) Sure :-) Also if there's a way we can avoid bugs in the default experience with minimal effort, we should. Anyway, there we go: changed the patch[*] to what's in Stretch. [*] https://review.openstack.org/#/c/558171/ -- /kashyap _______________________________________________ OpenStack-operators mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators