[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
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. Agreed, having investigated the bug, I know where it is, it can be fixed after you push the series, I will propose a patch to fix this. 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. 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 |