netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarod Wilson <jarod@redhat.com>
To: Edward Cree <ecree@solarflare.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	Michal Kubecek <mkubecek@suse.cz>,
	Netdev <netdev@vger.kernel.org>
Subject: Re: [RFC] bonding driver terminology change proposal
Date: Wed, 15 Jul 2020 15:23:37 -0400	[thread overview]
Message-ID: <CAKfmpSdS0Ckm4eA0hKECLNFvQo3nYU93N-oYO_wMeHoVGszA3g@mail.gmail.com> (raw)
In-Reply-To: <e515b840-c6f1-bc07-9369-c95e352573b2@solarflare.com>

On Wed, Jul 15, 2020 at 8:57 AM Edward Cree <ecree@solarflare.com> wrote:
>
> Once again, the opinions below are my own and definitely do not
>  represent anything my employer would be seen dead in the same
>  room as.
>
> On 13/07/2020 23:41, Stephen Hemminger wrote:
> > As far as userspace, maybe keep the old API's but provide deprecation nags.
> Why would you need to deprecate the old APIs?
> If the user echoes 'slave' into some sysfs file (or whatever), that
>  indicates that they don't have any problem with using the word.
> So there's no reason toever remove that support — its _mere
>  existence_ isn't problematic for anyone not actively seeking to be
>  offended.
> Which I think is more evidence that this change is not motivated by
>  practical concerns but by a kind of performative ritual purity.
>
> This is dumb.  I suspect you all, including Jarod, know that this
>  is dumb, but you're either going along with it or keeping your
>  head down in the hope that it will all blow over and you can go
>  back to normal.  Unfortunately, it doesn't work like that; the
>  activists who push this stuff are never satisfied; making
>  concessions to them results not in peace but in further demands;
>  and just as the corporations today are caving to the current
>  demands for fear of being singled out by the mob, so they will
>  cave again to the next round of demands, and you'll be back in
>  the same position, trying to deal with bosses wanting you to
>  break uAPI without even a technical reason.
> And next time around, the mob will be bolder and the bosses more
>  pliant, because by giving in this time we'll have signalled that
>  we're weak and easily dominated.  I would advise anyone still in
>  doubt of this point to read Kipling's poem "Dane-geld".
> And we'll all be left wondering why kernel development is so
>  soulless and joyless that no-one, of _any_ colour, aspires to
>  become a kernel hacker any more.
>
> It's not too late to stop the crazy, if we all just stop
>  pretending it's sane.

No, it isn't a practical code concern motivating this change, it's
actually quite impractical from a code standpoint and has no technical
merit. I understand your position, but having seen many emotional
responses to issues surrounding this, I think it's a worthwhile effort
that many people actually do appreciate. Even if I'm not personally
offended by the terminology, as a white male, I don't think I possess
the life experiences to downplay the negative impact ongoing use of
terms like "slave" might have on people that are actual descendants of
slavery. Embracing and helping move forward social change seems like a
responsible thing to do here, as long as we can do it without breaking
the kernel and UAPI.

-- 
Jarod Wilson
jarod@redhat.com


  reply	other threads:[~2020-07-15 19:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13 18:51 [RFC] bonding driver terminology change proposal Jarod Wilson
2020-07-13 21:36 ` Eric Dumazet
2020-07-14 18:01   ` Jarod Wilson
2020-07-13 22:00 ` Michal Kubecek
2020-07-13 22:41   ` Stephen Hemminger
2020-07-14  0:09     ` Michal Kubecek
2020-07-14  0:26     ` Andrew Lunn
2020-07-16  3:04       ` Jarod Wilson
2020-07-16  3:18         ` Andrew Lunn
2020-07-16  5:43           ` Jarod Wilson
2020-08-13  3:42             ` Jarod Wilson
2020-07-14  0:55     ` Jay Vosburgh
2020-07-14 18:15       ` Jarod Wilson
2020-07-15 12:56     ` Edward Cree
2020-07-15 19:23       ` Jarod Wilson [this message]
2020-07-14  1:00   ` David Miller
2020-07-16  3:06     ` Jarod Wilson
2020-07-16 18:59       ` David Miller
2020-07-16 23:01         ` Stephen Hemminger
2020-07-14 18:04   ` Jarod Wilson
2020-07-14  0:51 ` David Miller
2020-07-14 19:17 ` Toke Høiland-Jørgensen
2020-07-14 20:39   ` Marcelo Ricardo Leitner
2020-07-14 21:24     ` Jarod Wilson

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=CAKfmpSdS0Ckm4eA0hKECLNFvQo3nYU93N-oYO_wMeHoVGszA3g@mail.gmail.com \
    --to=jarod@redhat.com \
    --cc=ecree@solarflare.com \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --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).