[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20201002.155312.133560326274339745.davem@davemloft.net>
Date: Fri, 02 Oct 2020 15:53:12 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: stephen@...workplumber.org
Cc: jarod@...hat.com, linux-kernel@...r.kernel.org,
j.vosburgh@...il.com, vfalico@...il.com, andy@...yhouse.net,
kuba@...nel.org, tadavis@....gov, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 6/6] bonding: make Kconfig toggle to
disable legacy interfaces
From: Stephen Hemminger <stephen@...workplumber.org>
Date: Fri, 2 Oct 2020 12:13:17 -0700
> On Fri, 2 Oct 2020 13:40:01 -0400
> Jarod Wilson <jarod@...hat.com> wrote:
>
>> By default, enable retaining all user-facing API that includes the use of
>> master and slave, but add a Kconfig knob that allows those that wish to
>> remove it entirely do so in one shot.
>
> This is problematic. You are printing both old and new values.
> Also every distribution will have to enable it.
>
> This looks like too much of change to users.
Agreed, no Kconfig knob.
Keep everything during the deprecation period, then you can kill off
the old names at the end of the deprecation period.
I don't want to create a situation where distribution X lists as a
"feature" that they are able to enable this Kconfig value even though
it breaks UAPI for legacy external code out there.
That's the wrong way to go about this and creates the wrong incentive
system.
I also agree that you can't change the docs to stop mentioning the old
names. It's almost like we are pretending we aren't doing the
transition and that only the new names matter. The old names matter
and must therefore be acknowledged, exist, and be referencable in the
documentation until the end of the deprecation period. You can mark
them "(DEPRECATED)" or similar, but they can't be removed just yet.
Thank you.
Powered by blists - more mailing lists