On Tue, Feb 23, 2016 at 06:42:16PM +0000, Peter Maydell wrote: > On 23 February 2016 at 18:34, Wei Huang <w...@redhat.com> wrote: > > On 02/22/2016 04:14 PM, Peter Maydell wrote: > >> My view here is the same as it has been in the past regarding > >> adding versioned machine types for 'virt': are you (in this case > >> Redhat) willing to stand behind it, in the sense of taking on > >> the maintenance burden of adding new machine versions, reviewing > >> new code contributions for issues that require changes to make sure > >> that the old versions stay looking like the old machine, testing > >> that old versions look right, testing cross version migration, > >> and so on? > > > > I understand your concerns. Currently our in-house tree already carries > > versioned ARM machine types, which mirror both QEMU 2.4 and QEMU 2.5. > > Thus someone (including myself) from Red Hat shouldn't have any problem > > of maintaining/testing it because we are already doing it downstream. > > x86 and ppc have a similar situation. > > Thanks for the clarification -- if you as a distro are already > supporting versioned machine types downstream that's a strong > argument for adding it upstream.
Unfortunately the word 'support' is super overloaded in this field. I'll just quick clarify. We have a series of pre-releases for our virt stack. Later pre-release releases are based on later QEMU, and thus we've versioned mach-virt already. But, as they're just pre-releases, they aren't supported in the sense that we're working bug reports against them. I believe our downstream versioning has driven some changes to libvirt already, so I think it's a good time to bring the how to best version mach-virt discussions to all the respective upstreams, despite it currently, at least for us, being used only on pre-releases though. Thanks, drew
