On 24 February 2016 at 02:09, Andrew Jones <[email protected]> wrote: > 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.
So, to sum up from a conversation today: * We should add versioning to 'virt' now * We should do it by having the QEMU 2.6 release have a "virt-2.6" which is the same as "virt" for this upstream release * Then from 2.6 forward we start creating "virt-2.7", etc machines and making sure we have properties etc so that "virt-2.6" remains the same config as the 2.6 release's virt board. * RedHat are doing this for downstream anyway so will take on the task of monitoring changes to the virt board and submitting the relevant patches to property-ify things. (Better still, if you make comments during code review you can get patch submitters to do the work for you ;-). I will attempt to spot this kind of thing when I review patches to the virt board but I will probably miss things especially at first.) Practically: * Wei, you need to respin this patchset, because as it stands it creates a "virt-2.5", and it should be "virt-2.6". If you do that then I think it's generally OK to go in. * My only other review comment is that patch 1 sets mc->is_default which gives qemu-system-aarch64 a default board. We deliberately don't have a default machine type for ARM, so please don't do that. (We can have that discussion if you like but it's a separate issue so best not tangled up with this patchset.) thanks -- PMM
