On 01/14/2014 04:43 PM, Eric Blake wrote: > v2 of my patch series started here, after applying all patches > already reviewed in that thread: > https://www.redhat.com/archives/libvir-list/2013-December/msg01284.html > > Patches 1-3 can be considered bug fixes (particularly patch 3), > so I'd like them in 1.2.1 if they get a favorable review. Patches > 4-6 are less urgent, but might as well finish the work all within > one release. > > Patch 1 comes from 5/24 in v1 > Patch 2 is new > Patch 3 and 4 come from 23/24 in v1 > Patch 5 is new > Patch 6 comes from 24/24 in v1 > > Eric Blake (6): > maint: don't leave garbage on early API exit > maint: avoid nested use of virConnect{Ref,Close} > maint: don't lose error on canceled migration > maint: clean up error reporting in migration > maint: simplify driver registration at startup > maint: replace remaining virLib*Error with better names > > cfg.mk | 10 -- > src/libvirt.c | 397 ++++++++++++++++++++----------------------- > src/lxc/lxc_process.c | 11 +- > src/qemu/qemu_driver.c | 12 +- > src/qemu/qemu_migration.c | 14 +- > src/qemu/qemu_process.c | 10 +- > src/storage/storage_driver.c | 5 +- > src/uml/uml_driver.c | 3 +- > 8 files changed, 209 insertions(+), 253 deletions(-) > Patch 3 seems to be the one where there would be a couple of migration fixes that could use a backport, especially the change in virDomainMigrateVersion3Full() where the code now actually honors the condition where the uri was not set rather than just playing dumb. I also keep looking the changed "single" (!ret) to a "multi-state" (!ret && !xxx) condition and keep asking myself could we run into a situation where (!ret and xxx) is true where previously we'd fail on the !ret, but now wouldn't because xxx was true (where xxx is retcode or cancelled). Another "step" to consider for patch 5 would be to make common the repetitive code that follows the virDriverCheckTabMaxReturn(), e.g. VIR_DEBUG('string') table[count] = driver return count++ I don't see a reason other than proximity to release date to preclude inclusion in 1.2.1 ACK series in general though. John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list