> > GitHub is apparently looking into it as well: > https://www.bbc.com/news/technology-53050955
Yep, it seems like a few places are, that is why I think we should delay any branch renaming until bigger providers can come to a consensus, I don't want to have to make this change twice. > FWIW when you clone (from GitHub at least), you get the default branch, > whether it is named "master" or not. I'm not sure this covers all access paths. Given the concern on the linked thread from git-core, I really think we should wait until there is consensus and the core git developers/providers can come to a consensus. > Yes, and there are some reasonable arguments in there for why "main" is a > better choice than other alternatives. I was surprised how little > bikeshedding there was. There was also at least one linked thread about how "main" is problematic in non-english speaking languages. I'd prefer to let others bikeshed the naming for us :) On Fri, Jun 19, 2020 at 9:55 AM Neal Richardson <neal.p.richard...@gmail.com> wrote: > Thanks for the discussion, folks. I'm curious to hear what others think as > well. > > Some responses inline. > > Neal > > On Thu, Jun 18, 2020 at 9:24 PM Micah Kornfield <emkornfi...@gmail.com> > wrote: > >> sorry for the multiple posts ... I will also note that there is a lot of >> debate on this change on the linked thread as well (and I'm not sure the >> actual change will happen soon). >> >> On Thu, Jun 18, 2020 at 9:19 PM Micah Kornfield <emkornfi...@gmail.com> >> wrote: >> >> > FWIW Discussion on git core on naming [1], seems like it might be >> > coalescing around "main". >> > >> > [1] https://lore.kernel.org/git/20200615205722.GG71506@syl.local/ > > > Yes, and there are some reasonable arguments in there for why "main" is a > better choice than other alternatives. I was surprised how little > bikeshedding there was. > > >> >> > >> > On Thu, Jun 18, 2020 at 5:27 PM Micah Kornfield <emkornfi...@gmail.com> >> > wrote: >> > >> >> I'm in favor of trying to align on neutral language within the >> codebase. >> >> >> >> On branch naming, I think we should wait a little to see if a consensus >> >> converges on a new naming convention at least within Git/Github. > > > GitHub is apparently looking into it as well: > https://www.bbc.com/news/technology-53050955 > > >> On a >> >> technical level, I'm not sure if automated tooling (e.g. crawlers) >> outside >> >> of the project might make assumptions about default branch names or >> what >> >> is available in the github API for this type of metadata retrieval. >> > > "default_branch" is already an attribute of "repository" objects in GitHub > API responses > > >> >> >> >> Thanks, >> >> Micah >> >> >> >> On Thu, Jun 18, 2020 at 1:48 PM Wes McKinney <wesmck...@gmail.com> >> wrote: >> >> >> >>> On Thu, Jun 18, 2020 at 3:33 PM Antoine Pitrou <anto...@python.org> >> >>> wrote: >> >>> > >> >>> > >> >>> > Hi, >> >>> > >> >>> > Le 18/06/2020 à 21:56, Neal Richardson a écrit : >> >>> > > Hi all, >> >>> > > As you're likely aware, there's growing momentum in the developer >> >>> community >> >>> > > to drop terminology that some find offensive. >> >>> > >> >>> > Yes. Is it reasonable? Does it achieve anything? Is there any >> sense >> >>> > in trying to "drop terminology that some find offensive"? >> > >>> >> >>> We wish to create a community that is open and as inclusive and >> >>> welcoming as possible. So yes, IMHO if there is something that some >> >>> people might find offensive (even if it is not intended that way), >> >>> then there is value in removing that possibility from the equation. >> >>> We're here to build a healthy community that builds software together >> >>> and so respecting the perspectives of others (even if we disagree with >> >>> them) is a part of having a healthy community. >> >>> >> >>> > > >> >>> > As a project that takes pride >> >>> > > in being welcoming and inclusive, I think this is something we >> >>> should get >> >>> > > in front of--particularly as we're approaching a 1.0 release. >> >>> > >> >>> > I don't think we would get "in front of". We would just be >> following >> >>> > the "growing momentum". In other words, we would do something >> because >> >>> > it's popular. >> >>> >> >>> Repeating sentiments from my response a few minutes ago, I think it is >> >>> better for us to avoid even the possibility of these concerns arising >> >>> in this project. Let us spend our energy debating technical issues >> >>> rather than social or political ones. >> >>> >> >>> > (I'll note that the urge to follow the "growing momentum" is how the >> >>> > developer community standardised on irritating tools like Git) >> >>> > >> >>> > In the long term, and in the face of the problems that it claims to >> >>> > address, this seems futile to me. But it makes some people feel >> good >> >>> > about doing something, and it's (small) PR for the project... >> >>> > >> >>> > Now to the specifics: >> >>> > >> >>> > > Specifically, I am proposing to: >> >>> > > >> >>> > > 1. rename the "master" branch to something else ("main" seems to >> be >> >>> > > popular; other version control systems use other words too). >> >>> > >> >>> > I used Mercurial before Git, and Mercurial uses "default". I used >> SVN >> >>> > before Mercurial, and SVN uses "trunk". I don't remember if CVS is >> >>> > sophisticated enough to have any name for this concept :-) >> >>> > >> >>> > The problem, though, is that "master" is the overwhelming >> convention in >> >>> > Git land. Well-known conventions make a better user experience (you >> >>> > clone a git repo, you get the "master" branch and you know it: >> done). >> > > FWIW when you clone (from GitHub at least), you get the default branch, > whether it is named "master" or not. > > >> >>> > >> >>> > If we choose a non-"master" name, we add an additional hoop to jump >> >>> > through for users to approach Arrow. It's a small thing, but >> usability >> >>> > is often about such small things. >> >>> >> >>> I'm not concerned about this, given that Arrow is already on the >> >>> sophisticated end of the spectrum for open source projects. >> >>> >> >>> > > 2. replace "whitelist"/"blacklist" in our code with something like >> >>> > > "allowlist"/"blocklist", or otherwise renaming. >> >>> > >> >>> > "allow"/"deny" sounds terser, and also seems more symmetric to me. >> >>> > Also, be careful: "block" is very close, unsafely close, to >> "black"... >> >>> > >> >>> > Regards >> >>> > >> >>> > Antoine. >> >>> >> >> >> >
