On Mon, Aug 3, 2020 at 1:38 PM Eric Engestrom <e...@engestrom.ch> wrote: > > On Monday, 2020-08-03 13:31:19 -0500, Jason Ekstrand wrote: > > On Mon, Aug 3, 2020 at 1:24 PM Eric Engestrom <e...@engestrom.ch> wrote: > > > > > > On Monday, 2020-08-03 10:30:29 -0500, Jason Ekstrand wrote: > > > > All, > > > > > > > > I'm sure by now you've all seen the articles, LKML mails, and other > > > > chatter around inclusive language in software. While mesa doesn't > > > > provide a whole lot of documentation (hah!), we do have a website, a > > > > code-base, and a git repo and this is something that we, as a project > > > > should consider. > > > > > > > > What I'm proposing today is simply re-naming the primary Git branch > > > > from "master" to "main". Why "main"? Because that's what GitHub has > > > > chosen "main" as their new default branch name and so it sounds to me > > > > like the most likely new default. > > > > > > > > As far as impact on the project goes, if and when we rename the > > > > primary branch, the old "master" branch will be locked (no > > > > pushing/merging allowed) and all MRs will have to be re-targeted > > > > against the new branch. Fortunately, that's very easy to do. You > > > > just edit the MR and there's a little drop-down box at the top for > > > > which branch it targets. I just tested this with one of mine and it > > > > seems to work ok. > > > > > > > > As far as other bits of language in the code-base, I'm happy to see > > > > those cleaned up as people have opportunity. I'm not aware of any > > > > particularly egregious offenders. However, changing the name of the > > > > primary branch is something which will cause a brief hiccup in > > > > people's development process and so warrants broader discussion. > > > > > > > > Thoughts? > > > > > > Definite +1 for me on the idea, but we do have a lot of tools and > > > processes with `master` baked in. I'll try and have a look at everything > > > to make sure everything supports the transition (some things will need > > > to support both the old and new names), but assuming no issue there this > > > would be a really good thing to do, and `main` is a good name. > > > > I did some grepping and I noticed that as well. Some of the tools > > such as the khronos sync scripts will have to change if/when Khronos > > repos make a similar transition. I expect that to happen but don't > > have a timeline. I'll try to keep you posted on those. > > The external things like Khronos should be easy enough to handle, I was > more concerned about internal things like the stable branches. > > > > > For the internal ones, if you wanted to make a MR for it, we can > > either land it with support for both ahead of the switch or we can > > make it the first commit that goes on the new "main" branch. In any > > case, I'm not in so much of a hurry that I think we need to make the > > switch ahead of getting tooling ready. > > No hurry either... except a branchpoint like the one happening in 2 > days is the perfect time to minimize issues, as we could have eg. > `master` for VERSION<20.2 and `main` for VERSION>=20.2 which would > make it trivial for tools to know which branch name to use based on > the VERSION file.
Pardon me for being a bit daft but what's the issue there? "main" will contain all of the commits in "master" with exactly the same SHAs. The tools shouldn't have to make a distinction, I wouldn't think. What am I missing? --Jason _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
