Re: [PATCH v2 0/2] migration: feature removals for 11.0

[Markus Armbruster <armbru@redhat.com>]

Peter Xu <peterx@redhat.com> writes:

> On Tue, Feb 17, 2026 at 12:25:20PM +0100, Markus Armbruster wrote:
>> Peter Krempa <pkrempa@redhat.com> writes:
>> 
>> > On Thu, Jan 15, 2026 at 17:55:01 -0500, Peter Xu wrote:
>> >> v2:
>> >> - Added R-bs
>> >> - Updated description for removing zero-blocks [Markus]
>> >> - Squashed the "fd: to file" test removal into the 2nd patch
>> >> - I dropped the COLO patch, I have a local patch to remove colo migration
>> >>   completely, but looks like we won't do it..  Let's leave it for later but
>> >>   do the rest first
>> >> 
>> >> This series removes two deprecated features for 11.0.
>> >> 
>> >> Please review, thanks.
>> >> 
>> >> Peter Xu (2):
>> >>   migration: Remove zero-blocks capability
>> >>   migration: Remove fd: support on files
>> >> 
>> >>  docs/about/deprecated.rst             | 20 -------------
>> >
>> > Note that per the 'MAINTAINERS' file, changes to any deprecations ought
>> > to be CC'd to the libvirt list for visibility.
>> >
>> > In this case we've forgotten about the deprecation and didn't fix it
>> > before the qemu cahnge was pushed. I'll send out patches soon, but keep
>> > in mind to *always* CC the libvirt list with deprecations.
>> 
>> Review fail (mine).
>
> I confess I didn't notice this hard requirement when posting deprecation
> patches.  I definitely kept in mind of libvirt all the time, it's just that
> for this one since it used to be discussed well I didn't expect this to
> cause any surprise.
>
>> 
>> Should we try to make checkpatch.pl catch it?  So far, it doesn't check
>> cc: at all.
>
> I don't know if that'll work because logically we can also copy anyone or
> lists only when sending patches (e.g. with "git send-email --cc")..

For what it's worth, scripts/get_maintainer.pl would have told us to cc:
libvirt with this line:

    devel@lists.libvirt.org (open list:Incompatible changes)

> For now, I'll just remember to always copy libvirt list on touching
> deprecation file.  My apologize if it caused any unwanted surprise.

We cannot and do not expect a patch submitter to know and remember
everything.  We rely on tooling and review to catch misses in time.
Doesn't always work, because nothing and nobody's perfect.