On Fri, 2014-07-18 at 16:15 +0200, Andreas Färber wrote: > Am 17.07.2014 19:00, schrieb Paolo Bonzini: > > Il 17/07/2014 18:47, Michael Roth ha scritto: > >>> > My argument for getting this into 2.1 had been to avoid tools > >>> picking up > >>> > these to-be-renamed property names from the start. At this point, I'm > >>> > not so sure whether it's worse to break management tools or > >>> potentially > >>> > some rarely used/tested option - if we decide for 2.2, is > >>> backporting to > >>> > 2.1.1 an option if we document it in the release notes? > >> IMO, if there's some risk to breaking management or other tools, I'd > >> rather it be left to major releases. And if these values are already > >> misnamed > >> for 2.1.0 and prior, I don't think we stop it from poliferating much > >> more by > >> pushing the fix up by a few months. > > > > I'm not sure in which case management could break (except for qom-get). > > Andreas, can you explain? > > I was mainly concerned about qom-set, but same goes for qom-get. The > breakage would be in 2.2, if in 2.1 we introduce properties with foo_bar > and rename them to foo-bar in 2.2. Since they're not in 2.0, I had asked > Marcel to rename them for 2.1 on a KVM call. > > I checked that sPAPR is not affected, so the only issue is the trivial > g_free(). Since apart from sPAPR we have a compact snippet of properties > being added, grep'ing for occurrences of the old strings and verifying > that the patch changes all properties should be safe for -rc3 if Peter > would be willing to take a pull. Hi,
The patch only affects machine properties. The patch will be upstream in a few minutes. Sorry for the delay. Thanks, Marcel > > Andreas >
