git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Whinis <Whinis@whinis.com>
To: philipoakley@iee.email
Cc: Whinis@whinis.com, bturner@atlassian.com, git@vger.kernel.org,
	james@jramsay.com.au, me@ttaylorr.com, msuchanek@suse.de,
	peff@peff.net
Subject: Re: Consensus on a new default branch name
Date: Thu, 2 Jul 2020 17:59:51 -0400	[thread overview]
Message-ID: <d02a4b0c-71a1-5c83-a2f5-5e5f2168e5c4@whinis.com> (raw)
In-Reply-To: <4bbc8658-4dad-10ef-65a4-8f0f4f4fffd4@iee.email>

> The earliest claim I can find is from 2003, verified at Snopes in 2007
> [1] and reported in 2003 at [1] (and elsewhere)
>
> I would not expect that the original complaint had been withdrawn. I
> don't know if the relevant US/local laws have changed.
Not exactly proof in this sense nor proof they had an actual grievance 
as someone in US law might tell you. Sadly it was rather recently a 
lawyer would go around claiming to be disabled or speak for an unnamed 
disabled citizen and sue every single restaurant they came across for 
ADA violations. Same was done recently with a Lebowits but for copyright 
law where its easy as a lawyer to sue continuously to get an easy 
settlement until you are disbarred. Even from that link the official 
that wrote the memo said

> “I do understand that this term has been an industry standard for 
> years and years and this is nothing more than a plea to vendors to see 
> what they can do,” he said. “It appears that some folks have taken 
> this a little too literally.”
>
> Sandoval said that he had already rejected a suggestion that the 
> county stop buying all equipment carrying the “master” and “slave” 
> labels and had no intention of enforcing a ban on such terms with 
> suppliers.
>
> A recent blog post on racial bias in AI [2] highlighted that "Algorithms
> are our opinions written in code",  just as many of our naming
> conventions are implicit stand-ins for unsurfaced opinions and biases.
>
There is a great deal of misunderstanding on the "bias" in AI and in AI 
in general. I think you may have linked the wrong comment as [2] goes to 
a BBC story on the same story as the snopes article. However if you are 
talking about the recent depixelator it was shown to have similar 
performance if you darkened the images. This is not a bias its a 
technological limitation as darker images have less contrast on facial 
features, its also a well known issue in photography where its difficult 
to get enough dynamic range to properly expose an image with both 
darkskin and light skin individuals. Outside of extremely expensive 
cameras that even professional photographers don't want to use the 
technology is not in the hands of people to take proper photos with the 
needed dynamic range. This is also why lighting in films and TV are so 
important.

I feel a great many people want to attribute bias due to lack of data 
whenever no bias exists.

> One area that is far more obvious in the UK, is the use of euphemisms
> and innuendo, which can be grossly misused. It is quite easy to create
> subtlety different phrases which actively discriminate that wouldn't be
> noticed except by the careful or 'in the know' listener.  This can
> easily be done with 'master' in Git.

Unless you are making some allegation that anyone using the word master 
is racists or that somehow every technical field is inherently racists I 
have no idea why you are claiming its the same as actively 
discriminating. Or maybe you are trying to say the UK using its 
euphemisms is trying to be covertly racists? It would do well to clear 
up this confusing reference as it currently could be seen as insulting 
or making implications which clearly do not exists.

>  From a comment in [3], the link [4] provides details of the association
> of 'master' with 'slave' in Engineering literature, beginning in 1904
> for a pendulum & clock arrangement. In electronic clock circuits it
> wasn't till 1966 the use extended to flip-flop circuits, while hydraulic
> master/slave cylinders started in 1959.
I am rather unsure why you are reference either. Maybe you mixed up 2 
and 3 because 3 has nothing on master or slave but as you have mentioned 
its orthogonal since git has no slave branch. 4 is a admittedly short 
paper as the author recognized that it could be its own doctoral thesis 
and only did a cursory search although many are using it as proof that 
no references exists prior to this time. It also adds its own heavy 
biases as mentioned in the paper while gill was the first to use the 
slave reference that they can find it was used for many years without 
much discussion and even when challenged it was determined it would be 
better than a much wordier alternative because it would be better 
understood. The paper also claim that Gill would be disapproving of the 
words use however has nothing to back this up considering they not only 
used the term but appearntly did so for many years afterwords at lectures.

> The other issue is that Git doesn't do unique masters anyway. If you
> have the correct commit hash you have a perfect, indistinguishable
> replica of the original object - It's not a master (in the old 'version
> control' sense) any more, so we don't need that name for local clone's
> branch, unless it happens to be copied as the remote tracking branch.
> Though that is orthogonal to this discussion.
How does each commit have a perfect indistinguishable replica of the 
original? My understanding is each commit is a record of changes 
compared to the last. As such only the first commit is truly 'perfect'

> As I understand the change process, this will not be the catastrophic
> change many are suggesting. Existing repositories will still continue
> working. New repositories will have options for choosing the defaults.
> The usual level of great care over backward compatibility is being taken.
Is it? Because it seems to be that its waved off as a necessary cost of 
changing "outdated" language.  Being that its been used now for at least 
110 years and being that its the understood vernacular and multiple 
projects and scripts assume, even if wrongly, the master branch is the 
one you should work from means changing this default is not usual great 
level of care. Certainly main seem to think its as simple as changing 
the letter and nothing will break. Sadly that rarely true

> Anyway, that's the back story, with references,  that I've been able to
> track down. Hope that helps.
Unfortuntely no as the references being asked for is who this change 
actually impacts. We could go to twitter but that has it owns biases and 
every issue on this topic outside of this mailing list is either locked 
or biases by assuming it must change and leaving out master or tainted 
due to brigading. Just based on what I have anecdotally seen however 
most of the people pushing for this change is not the affected minority 
group its claimed to help.

-Whinis


  reply	other threads:[~2020-07-02 21:57 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-15 20:57 Consensus on a new default branch name Taylor Blau
2020-06-15 21:10 ` Santiago Torres Arias
2020-06-15 21:21 ` Taylor Blau
2020-06-16 14:31   ` Jeff King
2020-06-16 14:52     ` Oleg
2020-06-16 16:00       ` Jeff King
2020-06-16 17:11         ` Oleg
2020-06-16 17:32           ` Konstantin Ryabitsev
2020-06-16 18:54             ` Oleg
2020-06-16 22:18           ` Jeff King
2020-06-16 16:10     ` Konstantin Ryabitsev
2020-06-16 16:13       ` Santiago Torres Arias
2020-06-16 16:48         ` Jeff King
2020-06-16 16:14       ` Jason Pyeron
2020-06-16 16:47       ` Jeff King
2020-06-16 17:44       ` Steve Litt
2020-06-16 19:00         ` Oleg
2020-06-17 18:06     ` Michal Suchánek
2020-07-01 17:31       ` Michal Suchánek
2020-07-01 21:57         ` Jeff King
2020-07-02 12:21           ` Whinis
2020-07-02 21:15             ` Philip Oakley
2020-07-02 21:59               ` Whinis [this message]
2020-07-02 22:47                 ` Philip Oakley
2020-07-02 23:08                   ` Whinis
2020-07-01 22:25         ` Jonathan Nieder
2020-06-15 22:38 ` Elijah Newren
2020-06-16 14:32   ` Jeff King
2020-06-17 20:13     ` Junio C Hamano
2020-06-15 23:24 ` brian m. carlson
2020-06-16  0:50 ` James Ramsay
  -- strict thread matches above, loose matches on Subject: below --
2020-06-16  1:58 Nomen Nescio
2020-06-16  2:22 ` Jonathan Nieder
2020-06-16  2:31   ` Taylor Blau
2020-06-16 14:38   ` Jeff King
2020-06-17  0:01 Anonymous Remailer (austria)

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=d02a4b0c-71a1-5c83-a2f5-5e5f2168e5c4@whinis.com \
    --to=whinis@whinis.com \
    --cc=bturner@atlassian.com \
    --cc=git@vger.kernel.org \
    --cc=james@jramsay.com.au \
    --cc=me@ttaylorr.com \
    --cc=msuchanek@suse.de \
    --cc=peff@peff.net \
    --cc=philipoakley@iee.email \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).