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 > > >
