Hi all, I would not oppose the renaming, but I must say that I agree with Danny Chan here. Is this really an issue? Is there any official guideline from the ASF about this topic? Has anyone in the Calcite community truly expressed any concern about the master branch being called "master"? Do you really think of slavery whenever you "merge into master", or whenever you use the term "master" in this context?
I could understand renaming a "master-slave" architecture into something different, since that is clearly a slavery-related terminology. But, as other people have already said, not every usage of the word "master" has this connotation. Honestly I see no problem in having a "master branch" because, in my opinion, it is clear that when we talk about it we mean the "reference branch", "principal branch" or (quoting the Merriam-Webster dictionary) the "original from which copies can be made". Maybe I am wrong here, but I have the impression that we are fixing an artificial problem that does not actually exist. If tomorrow someone on Twitter says that the term "class" is offensive because it has some marxist connotations, should we rewrite all our Java code? This is an extreme, stupid example (I hope, although nowadays you never know), but I think you know where I am going with my logic... We need to fight racism but IMHO this is not how to do it. Best, Ruben Le mer. 29 juil. 2020 à 06:54, Francis Chuang <[email protected]> a écrit : > I am also +1 for this change. > > - It's a simple change that doesn't require a lot of effort and > disruption to the code base. > - If we follow the links from the article Michael posted, the term > "master" in git does not originate from "master record" but rather from > master/slave. > - We make our community more welcoming, diverse and inclusive by > switching to a term that is more inclusive. > - Sometimes a new word can be more self-explanatory. Recently > "blacklist" and "whitelist" was replaced in the Go source code with > "allowlist" and "blocklist" [1] as a case in point. > > Francis > > [1] https://go-review.googlesource.com/c/go/+/236857/ > > On 29/07/2020 12:30 pm, Matt Burgess wrote: > > Hi all, > > > > I'm a Calcite user and longtime mailing list lurker :) I'd like to > > share our experience from Apache NiFi, we started such a discussion > > for NiFi based on existing discussions from Apache Yetus and Apache > > Accumulo [1]. Our own discussion continued (please see the linked > > email thread) but I believe our community came to a similar consensus > > as the Calcite community (and others), that whatever notions were > > educed from the terms, it is more welcoming and purposeful to change > > them for the best community experience. The impact to the codebase was > > minimal and non-breaking, so we came together to perform the few steps > > we needed to rename the default branch and search the code for terms > > we could simply find-and-replace, plus we updated the Developer Guide. > > Since then, we haven't seen much in the way of confusion or missteps > > in our development process. Everyone seems to have taken the changes > > in stride, updated what they needed to, and continued with their > > contributions, all the while providing a better atmosphere for even > > better things to come. > > > > Regards, > > Matt > > > > [1] > http://mail-archives.apache.org/mod_mbox/nifi-dev/202006.mbox/%3cCA+LyY55Mb8xZ35W_9UM=ter+gt_1azhgxmbpdn9edbssnv-...@mail.gmail.com%3e > > > > On Tue, Jul 28, 2020 at 9:55 PM Danny Chan <[email protected]> wrote: > >> > >> As a Chinsese, I didn’t understand quite well why the word “master” can > be “slavery”. I often see it as the similiar meaning as “main”, it seems to > take some time to adapt to new term “main” because I believe most of the > developers got used to the word “master”. > >> > >>> I think this is a relatively low impact change that can potentially > >>> make us even more welcoming to new contributors, which is a benefit to > >>> us all :) > >> > >> Is this true ? People would always contribute to Calcite if they need > to, apparently not just because of a branch name. > >> > >> Best, > >> Danny Chan > >> 在 2020年7月29日 +0800 AM7:08，Michael Mior <[email protected]>，写道： > >>> Actually, the argument that the term "master" in git didn't originate > >>> from master/slave is not true. See the article I linked earlier. In > >>> any case, I don't think the change hurts anyone other than a brief > >>> annoyance when we all have to change our branch name and if it makes > >>> the project more welcoming to someone, than great. > >>> > >>> -- > >>> Michael Mior > >>> [email protected] > >>> > >>> > >>> Le mar. 28 juil. 2020 à 17:29, Julian Hyde <[email protected]> a > écrit : > >>>> > >>>> I agree with you. It’s probably derived from “master” as in the “gold > master” [1] which is the mix from which a sound engineer would cut a record > or CD. And who knows where that term came from? > >>>> > >>>> But in the end, the origin of the term is irrelevant. The current > name is, or may be, unwelcoming to some people, so let’s just move on. > >>>> > >>>> Julian > >>>> > >>>> [1] https://en.wikipedia.org/wiki/Mastering_(audio) < > https://en.wikipedia.org/wiki/Mastering_(audio)> > >>>> > >>>>> On Jul 28, 2020, at 1:56 PM, Viliam Durina <[email protected]> > wrote: > >>>>> > >>>>> It's not a term related to slavery, it has much broader meaning than > "slave > >>>>> owner", but any argument is probably vain. > >>>>> > >>>>> On Tue, 28 Jul 2020 at 19:43, Julian Hyde <[email protected]> > wrote: > >>>>> > >>>>>> I am in favor of renaming ‘master’ to ‘main’. To most people it > doesn’t > >>>>>> make any difference. To some, such as potential members currently > outside > >>>>>> the community, it makes the project more welcoming. > >>>>>> > >>>>>> Very little effort or disruption is required. We’ve identified a > potential > >>>>>> source of friction, so let’s fix it and move on. > >>>>>> > >>>>>> Julian > >>>>>> > >>>>>>> On Jul 28, 2020, at 10:31 AM, Michael Mior <[email protected]> > wrote: > >>>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> You can find some background on this discussion at the link below > [0]. > >>>>>>> This is a topic that has come up regularly among D&I folks at the > ASF. > >>>>>>> The short summary is that the term "master" when referring to a git > >>>>>>> branch is a reference to terminology related to slavery. I'm > >>>>>>> suggesting main because this seems to be what the developer > community > >>>>>>> as a whole is gravitating towards. See for example, GitHub's public > >>>>>>> roadmap [1] where there are plans to make this change. > >>>>>>> > >>>>>>> I'm hoping that this discussion can be focused not on whether > anyone > >>>>>>> has been impacted by such terminology, but how we can move > forward. I > >>>>>>> personally believe that if a single person feels more welcome to > >>>>>>> contribute because of the change, it's a win. I also don't think > >>>>>>> making this change needs to be painful. (There are less than 20 > >>>>>>> relevant references to "master" in the Calcite code.) Apache Mahout > >>>>>>> and I believe others have already made this change. > >>>>>>> > >>>>>>> I think this is a relatively low impact change that can potentially > >>>>>>> make us even more welcoming to new contributors, which is a > benefit to > >>>>>>> us all :) > >>>>>>> > >>>>>>> [0] > >>>>>> > http://www.kapwing.com/blog/how-to-rename-your-master-branch-to-main-in-git/ > >>>>>>> [1] https://github.com/github/roadmap/issues/63 > >>>>>>> > >>>>>>> -- > >>>>>>> Michael Mior > >>>>>>> [email protected] > >>>>>> > >>>>>> > >>>>> > >>>>> -- > >>>>> Viliam Durina > >>>>> Jet Developer > >>>>> hazelcast® > >>>>> > >>>>> <https://www.hazelcast.com> 2 W 5th Ave, Ste 300 | San Mateo, CA > 94402 | > >>>>> USA > >>>>> +1 (650) 521-5453 | hazelcast.com <https://www.hazelcast.com> > >>>>> > >>>>> -- > >>>>> This message contains confidential information and is intended only > for the > >>>>> individuals named. If you are not the named addressee you should not > >>>>> disseminate, distribute or copy this e-mail. Please notify the sender > >>>>> immediately by e-mail if you have received this e-mail by mistake and > >>>>> delete this e-mail from your system. E-mail transmission cannot be > >>>>> guaranteed to be secure or error-free as information could be > intercepted, > >>>>> corrupted, lost, destroyed, arrive late or incomplete, or contain > viruses. > >>>>> The sender therefore does not accept liability for any errors or > omissions > >>>>> in the contents of this message, which arise as a result of e-mail > >>>>> transmission. If verification is required, please request a hard-copy > >>>>> version. -Hazelcast > >>>> >
