Re: Request a freeze exception for Libxl Migration v2 in 4.6

[Yang Hongyang <yanghy@cn.fujitsu.com>]

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.