netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Williams, Dan J" <dan.j.williams@intel.com>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"amitc@mellanox.com" <amitc@mellanox.com>,
	"david@protonic.nl" <david@protonic.nl>,
	"linville@tuxdriver.com" <linville@tuxdriver.com>,
	"marex@denx.de" <marex@denx.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"petrm@mellanox.com" <petrm@mellanox.com>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"christian.herber@nxp.com" <christian.herber@nxp.com>,
	"mkubecek@suse.cz" <mkubecek@suse.cz>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"o.rempel@pengutronix.de" <o.rempel@pengutronix.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"mkl@pengutronix.de" <mkl@pengutronix.de>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>
Subject: Re: [PATCH ethtool v1] netlink: add master/slave configuration support
Date: Tue, 9 Jun 2020 19:30:50 +0000	[thread overview]
Message-ID: <4d664ff641dbf3aeab1ecd5eacda220dab9d7d17.camel@intel.com> (raw)
In-Reply-To: <20200609.113633.1866761141966326637.davem@davemloft.net>

On Tue, 2020-06-09 at 11:36 -0700, David Miller wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Tue, 9 Jun 2020 10:19:35 -0700
> 
> > Yes, words do matter and convey a lot of implied connotation and
> > meaning.
> 
> What is your long term plan?  Will you change all of the UAPI for
> bonding for example?

The long term plan in my view includes talking with standards bodies to
move new content to, for example, master/subordinate. In other words,
practical forward steps, not retroactively changing interfaces.

> Or will we have a partial solution to the problem?

Partial steps toward better inclusion are meaningful.

The root problem is of course much larger than a few changes to
technical terminology could ever solve, but solving *that* problem is
not the goal. The goal is to make the kernel community as productive as
possible and if the antropomorphic association of "slave" can be
replaced with a term that maintains technical meaning it makes kernel-
work that much more approachable.

I recall one of Ingo's explanations of how broken whitespace can make
patches that much harder to read and take him out of the "zone" of
reviewing code. "Slave" is already having that speed bump affect on the
community. If we can replace it without losing meaning and improving
the effectiveness of contributors I think the Linux kernel project is
better for it.

  parent reply	other threads:[~2020-06-09 19:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26  9:10 [PATCH ethtool v1] netlink: add master/slave configuration support Oleksij Rempel
2020-05-26 12:41 ` Michal Kubecek
2020-05-27 10:26   ` Oleksij Rempel
2020-06-07 22:30 ` Stephen Hemminger
2020-06-07 23:45   ` David Miller
2020-06-09 17:19     ` Stephen Hemminger
2020-06-09 18:30       ` Andrew Lunn
2020-06-09 18:36       ` David Miller
2020-06-09 19:29         ` Kees Cook
2020-06-09 19:34           ` David Miller
2020-06-09 19:49             ` Kees Cook
2020-06-09 20:05               ` David Miller
2020-06-09 20:29                 ` Kees Cook
2020-06-09 20:53                   ` Michal Kubecek
2020-06-09 21:34                     ` Kees Cook
2020-06-09 19:30         ` Williams, Dan J [this message]
2020-06-09 19:38           ` David Miller
2020-06-09 21:48             ` Dan Williams
2020-06-10  6:07               ` Oleksij Rempel
2020-06-09 18:46       ` Edward Cree
2020-06-09 20:31       ` Michal Kubecek

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=4d664ff641dbf3aeab1ecd5eacda220dab9d7d17.camel@intel.com \
    --to=dan.j.williams@intel.com \
    --cc=amitc@mellanox.com \
    --cc=andrew@lunn.ch \
    --cc=christian.herber@nxp.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=david@protonic.nl \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linville@tuxdriver.com \
    --cc=marex@denx.de \
    --cc=mkl@pengutronix.de \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=petrm@mellanox.com \
    --cc=stephen@networkplumber.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).