Hi, I'm now convinced that we will save time in the long run if we just change the name of our main branch from "master" to "main" sooner than later.
Any discussion? Volunteers? Craig > On 08/07/2021 18.25, Rich Bowen wrote: >> On 7/7/21 6:45 AM, Daniel Gruno wrote: >>> On 07/06/2021 19.48, Rich Bowen wrote: >>>> >>>> >>>> On 6/6/21 8:04 AM, Daniel Gruno wrote: >>>>> (switching to the new list) >>>>> >>>>> The VM is up and running at https://clc.diversity.apache.org/ >>>>> <https://clc.diversity.apache.org/> and has ASF Oauth implemented, so any >>>>> committer can make use of this service. >>>>> >>>>> I have added a few projects to try things out, seems to work. >>>>> >>>>> I suppose we should communicate this to all projects, so they may make >>>>> use of it? >> I drafted something here: https://hackmd.io/Scig_0a0R4K0_sADiQCJdA >> <https://hackmd.io/Scig_0a0R4K0_sADiQCJdA> > > Looks great, +1 to sending it out to projects :) > > Related, all ASF repositories have been cloned to our VM and scanned once. > Projects can log in via ASF OAuth and make adjustments to scan criteria as > needed. The scanner runs once every 24 hours. > On 7/9/21 10:44 PM, Craig Russell wrote: >> Before this gets out of hand, I have to object to flagging "master" as a git >> branch name without any other context like "slave". > > Pragmatically speaking, you have a choice here. It seems pretty clear to me, > having been at the center of this discussion for almost a year now, that the > industry *is* going to settle on removing this usage of the word master. So > you (we) can choose to flag it now, or we can wait a few years and be out of > step with the rest of the conversation. > > Kind of like how we resisted having a code of conduct for so many years, and > then just did it because it was embarrassing not to. > > Or we can choose to be leaders. > > Yes, there's an argument to be made that "master" is fine in context Z but is > a problem in context Q. I have been part of this conversation dozens of > times, at least. But ... why? This specific case is easier to remediate than > almost any of the other ones - you change a branch name, and you spend an > hour updating your tooling. It is by far the easiest win in this entire > effort. Unlike, say, altering function names that are based on libraries that > are based on IETF standards. > > -- > Rich Bowen - rbo...@rcbowen.com <mailto:rbo...@rcbowen.com> > @rbowen > > Begin forwarded message: > > From: Rich Bowen <rbo...@rcbowen.com> > Subject: Re: [Lazy consensus] request a VM for CLC for Apache projects > Date: July 12, 2021 at 11:30:31 AM PDT > To: Craig Russell <apache....@gmail.com> > Cc: d...@diversity.apache.org > > > > On 7/12/21 2:18 PM, Craig Russell wrote: >> Hi Rich, >> You have convinced me. We can either ignore this while the rest of the >> industry moves on or deal with it now. Either way, I doubt that the arc of >> thinking will come back to "this usage is just fine". >> Still, I'd like to say that no one here is going to force PMCs to act now. >> It is entirely up to each project if and when they change. > > Absolutely. Not only is it not the Apache way, we couldn't compel them to do > this even if we wanted to. Indeed, the projects I have already talked to (5 > or 6, with my work hat on) have been roughly split between, "yes, we need to > address this," and "This isn't a priority for us." > >> The nice thing about the tool is that it allows projects to focus on those >> items that are important to them. > > Yeah, the ability to configure which keywords they want to look at is really > important for the way that our projects self-govern. > > -- > Rich Bowen - rbo...@rcbowen.com > @rbowen Craig L Russell c...@apache.org
