All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: "Zhang Chen" <zhangckid@gmail.com>,
	"Lukas Straub" <lukasstraub2@web.de>,
	qemu-devel@nongnu.org, "Juraj Marcin" <jmarcin@redhat.com>,
	"Fabiano Rosas" <farosas@suse.de>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Juan Quintela" <quintela@trasno.org>,
	"Dr. David Alan Gilbert" <dave@treblig.org>,
	zhanghailiang@xfusion.com, "Li Zhijian" <lizhijian@fujitsu.com>,
	"Jason Wang" <jasowang@redhat.com>
Subject: Re: [PATCH 1/3] migration/colo: Deprecate COLO migration framework
Date: Fri, 16 Jan 2026 16:33:37 +0100	[thread overview]
Message-ID: <87ldhxtvvy.fsf@pond.sub.org> (raw)
In-Reply-To: <aWpGY9Y1dPwlBuw3@x1.local> (Peter Xu's message of "Fri, 16 Jan 2026 09:08:35 -0500")

Peter Xu <peterx@redhat.com> writes:

> On Fri, Jan 16, 2026 at 10:41:28AM +0100, Markus Armbruster wrote:
>> Zhang Chen <zhangckid@gmail.com> writes:
>> 
>> > On Fri, Jan 16, 2026 at 2:26 PM Markus Armbruster <armbru@redhat.com> wrote:

[...]

>> >> I think we should deprecate COLO now to send a clear distress signal.
>> >> The deprecation notice should explain it doesn't work, and will be
>> >> removed unless people step up to fix it and to maintain it.  This will
>> >> ensure progress one way or the other.  Doing nothing now virtually
>> >> ensures we'll have the same discussion again later.
>> >>
>> >> "Broken for two releases without anyone noticing" and "maintainer absent
>> >> for more than four years" doesn't exacltly inspire hope, though.  We
>> >> should seriously consider removing it right away.
>> >>
>> >> Lukas, can you give us hope?
>> >>
>> >
>> > Hi Markus,
>> > Maybe you missed something?
>> > I think Lukas is ready to maintain this code in his previous emails.
>> > https://lore.kernel.org/qemu-devel/20260115224516.7f0309ba@penguin/T/#mc99839451d6841366619c4ec0d5af5264e2f6464
>> 
>> Patch to MAINTAINERS or it didn't happen ;)
>
> I'd even say MAINTAINERS file is, in many cases, cosmetic..
>
> It definitely is helpful for people to do lookups or scripts to fetch
> information, but IMHO we need more than one single entry, and in some sense
> that entry is less important than the activities.
>
> We need someone to be first familiar with a piece of code, spend time on
> it, actively reply to the relevant queries upstream, proper testing /
> gating to make sure the feature is usable as stated - either fully
> maintained or odd fixes or others, and more.

Yes, we need a maintainer not just in name, but for real.

(My one-liner was an attempt at a joke)

> I used to request Lukas help reviewing the loadvm threadify series [1,2]
> which definitely touches COLO, I didn't really get a respond.  That's also
> a sign I don't feel like Lucas cares enough about COLO, after I explicitly
> pointing out something might be changing and might be risky.
>
> It's like Hailiang is also in the MAINTAINERS file but Hailiang is
> unfortunately not active anymore recently over the years.

We're bad at updating the MAINTAINERS file when maintainers have
wandered off.

> Frankly, it was Zhijian and Chen that were always helping from that regard.
> I would rather think anyone of both would be more suitable at least from
> all the discussions I had with COLO, but this is a promise I can't do.  I
> also still want to remove it as I proposed, in case it releases everyone.
>
> So an update in the file isn't even enough if we accept it.  We need
> activity corresponding to the file change.  That's also why I still think
> we should remove COLO regardless if 11.0 doesn't improve in this condition,
> as I stated in the other email.

Concur.

> [1] https://lore.kernel.org/qemu-devel/aSSx28slqi1ywg2v@x1.local
> [2] https://lore.kernel.org/all/20251022192612.2737648-1-peterx@redhat.com
>
> Thanks,



  reply	other threads:[~2026-01-16 15:34 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-14 19:56 [PATCH 0/3] migration: deprecations and removals for 11.0 Peter Xu
2026-01-14 19:56 ` [PATCH 1/3] migration/colo: Deprecate COLO migration framework Peter Xu
2026-01-14 20:11   ` Peter Xu
2026-01-15 21:49     ` Lukas Straub
2026-01-15 22:39       ` Peter Xu
2026-01-15 22:59         ` Dr. David Alan Gilbert
2026-01-15 23:38           ` Peter Xu
2026-01-16  0:37             ` Dr. David Alan Gilbert
2026-01-16  8:16               ` Zhang Chen
2026-01-16  7:47             ` Zhang Chen
2026-01-17 19:49             ` Lukas Straub
2026-01-17 20:15               ` Lukas Straub
2026-01-19 22:33               ` Peter Xu
2026-01-20 11:48                 ` Lukas Straub
2026-01-20 15:58                   ` Peter Xu
2026-01-20 19:04                     ` Dr. David Alan Gilbert
2026-01-20 19:50                       ` Peter Xu
2026-01-21  1:25                         ` Dr. David Alan Gilbert
2026-01-21 17:03                           ` Peter Xu
2026-01-21 17:31                             ` Dr. David Alan Gilbert
2026-01-21 20:22                               ` Peter Xu
2026-01-21 21:31                                 ` Dr. David Alan Gilbert
2026-01-21 22:22                                   ` Peter Xu
2026-01-16  7:05           ` Zhang Chen
2026-01-16  9:46           ` Daniel P. Berrangé
2026-01-16 13:56             ` Peter Xu
2026-01-16  6:26       ` Markus Armbruster
2026-01-16  8:22         ` Zhang Chen
2026-01-16  9:41           ` Markus Armbruster
2026-01-16 14:08             ` Peter Xu
2026-01-16 15:33               ` Markus Armbruster [this message]
2026-01-14 21:13   ` Dr. David Alan Gilbert
2026-01-15  5:56   ` Markus Armbruster
2026-01-15 18:53     ` Peter Xu
2026-01-14 19:56 ` [PATCH 2/3] migration: Remove zero-blocks capability Peter Xu
2026-01-15  6:00   ` Markus Armbruster
2026-01-15 18:53     ` Peter Xu
2026-01-14 19:56 ` [PATCH 3/3] migration: Remove fd: support on files Peter Xu
2026-01-14 22:10   ` Peter Xu
2026-01-15 12:15   ` Prasad Pandit
2026-01-15 17:39     ` Peter Xu
2026-01-15  6:11 ` [PATCH 0/3] migration: deprecations and removals for 11.0 Markus Armbruster
2026-01-15 18:58   ` Peter Xu
2026-01-15 14:37 ` Fabiano Rosas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ldhxtvvy.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dave@treblig.org \
    --cc=farosas@suse.de \
    --cc=jasowang@redhat.com \
    --cc=jmarcin@redhat.com \
    --cc=lizhijian@fujitsu.com \
    --cc=lukasstraub2@web.de \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@trasno.org \
    --cc=zhangckid@gmail.com \
    --cc=zhanghailiang@xfusion.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.