[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Request a freeze exception for Libxl Migration v2 in 4.6
Hi Ian, On 07/14/2015 10:13 PM, Ian Jackson wrote: Ian Jackson writes ("Re: Request a freeze exception for Libxl Migration v2 in 4.6"):Andrew Cooper writes ("Request a freeze exception for Libxl Migration v2 in 4.6"):I would like to request a freeze exception for libxl migration v2. v3 of the series was posted this morning, and review seems to indicate that it is mostly on track. I hope to have v4 ready to post tomorrow, and hope to have no further adjustments required.Wei asked me for input and I thought it best to reply by email.The series is now fully acked and there are only two things stopping it going in right away: * The need for a freeze exception which has not yet been granted. * We have a bug report about it breaking Remus. This is being investigated. My view as maintainer is that this should not be a blocker to committing this series, because: - This series is itself a prerequisite for Colo work, which is being promoted by many of the same people as Remus. - I have confidence that this bug will be resolved early during the freeze. In particular I have confidence (based on past performance) that the bug-hunt will be thorough, and that the submitter of this v2 migration series will quickly take responsibility and develop necessary fixes. I would like to get a confirmation from a Remus maintainer that they are happy with this approach: that is, to commit now, and fix later. I'm quite happy with this approach, and am definitely going to fix the bug asap. But after getting that confirmation, if it weren't for the freeze I would now be pushing this series to staging. Arguments in favour of the exception: * The series is a prerequisite for other important work (notably Colo), and even if that other work misses 4.6, we want to make as much progress as possible. * This series is cleanup work, rather than new functionality; we hope it will improve the release's long-term maintainability and quality. * The code quality of the initial non-RFC v1 was very high. * Without this series we will, for another release, have an entirely-unexercised set of `v2 migration' code at the libxc layer. * The series is now in good shape and only 3 working days late. Arguments against: * We are switching between implementations of a major piece of functionality. I would recommend granting an exception, subject to two conditions: * Confirmation from a Remus maintainer that they would prefer this series to go in now, and be fixed later, despite the probable existence of a Remus-related bug. * That the series should be committed today or tomorrow. Thanks, Ian. . -- Thanks, Yang. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |