Re: [External] Re: [PATCH v2 1/4] API: introduce memory failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/14/20 4:44 AM, zhenwei pi wrote:
I described it in '[PATCH v2 4/4] virsh: implement memory failure event'

Notice:
The full patch set includes 4 patches:
virsh: implement memory failure event         (current patch)
qemu: monitor: handle memory failure event
qemu: process: implement domainMemoryFailure
API: introduce memory failure

To avoid build/test errors, the 4 patches should be merged/removed
together.


Suggested by Peter, separate a 'all in one' patch into 4 patches (described in cover letter '[PATCH v2 0/4] support memory failure'). I forked a repo and pushed the 4 patches(https://gitlab.com/pacepi/libvirt/-/tree/memory-failure-v2), CI worked fine.

To add to Peter's reply: the reason we require each patch to build on its own is backport. You are not doing it necessarily in your series, but if for instance you'd move some code then:

1) it's a standalone change that should be in a separate patch
2) if a distribution wants to backport the patch (e.g. because it is a prerequisite for some other patch), then the code base should build without having to backport irrelevant patches.

And to some extent your patches can be viewed as backportable. I can imagine that somebody writes the code for other driver (say libxl) and a distro might want to backport it. It will need to backport this patch which adds the RPC and client facing APIs. But at the current state it can't do so because it won't compile.

Looking forward to v3.

Michal




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux