Robert A short but sweet reply.
I've not been involved actively in this project for long, heck I haven't really contributed more than a few fringe things in associating projects so I'm sure your valuable contributions over the years have pushed the project further than could of without your help. That being said, I think I'm aligned with the view that if even one person feels angst about the naming convention it's worth changing to make a better world. I really like how the whole community is working out how to do this in a measured manner and not a knee jerk e.g. waiting to find out what a new standard is, identifying how to implement it without disruption to the customers (API versions). A friend once told me, "just because people don't witness something personally, it doesn't mean it doesn't happen". Thank you to everyone working this through in a cohesive manner. Nat On Thu, Jun 18, 2020, 08:48 THORMAN, ROBERT D <[email protected]> wrote: > I have been associated with the Accumulo project since its inception and > many other AF/LF projects for decades. I have collaborated with many of > you since the Bigtable paper came out and the NSA started the project which > was release to the OS community as Cloudbase. My early adoption and use of > Accumulo has result in many deployments and operations in both public and > private spaces. Never in my 30 year experience as a software engineer > working with people from vase ethnical backgrounds has the issue of racism > with respect to the term "master" and "slave" ever came up. Some of my > favorite people in the world are different color than I am and I have never > felt anything but admiration for their contributions to the OS communities, > yet this issue has never even been mentioned before. This is a classic > case of creating an issue that doesn't exist. > > So, please allow my dissenting opinion to be on record: I think this is > the dumbest thing I have ever witnessed in my 30 years of software > engineering. The sheer number of defects that will be caused by this > semantic change borders on insanity in my book. There is zero value add to > this and the resentment it will cause will be worse than the original > miss-perception. Inexcusable! > > I have a multi-racial family and love every person regardless of their > ethnicity or color. But this is stupid. > > Bob Thorman > Former Accumulo project member > > On 6/18/20, 7:27 AM, "Brian Loss" <[email protected]> wrote: > > +1 to the ranked choice idea. I also think it makes sense to give > GitHub and/or ASF a little time to select a default/main branch name. It > would be nice to keep with the standard for the ecosystem since it appears > GitHub is switching away from master as a default branch name too. > > There does appear to be a reference to master in the client API: > Instance.getMasterLocations(). I believe, according to semver, we’ll have > to deprecate that but cannot remove it until version 3. > > > On Jun 17, 2020, at 11:22 PM, Christopher <[email protected]> > wrote: > > > > I'm in favor of the change. > > > > We can change the git branch names pretty easily, and am willing to > do > > the legwork on that part. I've already checked with INFRA to > determine > > the extent of the consequences, and it looks like it should be > > minimal, with the right coordination. However, I have been waiting to > > bring it up on list until the larger ASF and GitHub open source > > communities have converged on a preferred alternative name. The ones > > I've seen suggested most are "main/primary/default". I like "main" > and > > "default", but would prefer to stick with whatever convention seems > to > > have the most momentum globally, so we're staying with the > mainstream. > > "main" seems to be gaining the most traction, but I would give it > > another week or two before we know for sure. > > > > For the accumulo server, this is going to be a little rough. Most > > internal names and references can be changed relatively easily > without > > disruption. The main breakages would be Thrift API, ZooKeeper storage > > locations, Monitor XML/JSON, KeywordExecutable/scripts, and property > > names, with property names being the most user-facing (unless we have > > a public API with references to the "master", which I don't think we > > do). Many of these changes can be done independently and > > incrementally, and we can try to hold off on breaking changes until > > 3.0, but it will take work to retain compatibility before then. > > > > I like the idea to do ranked choice voting to select a name for the > > server. Let's do that in a new thread, so we can just focus on name > > selection there. As for actually making changes... Mike Wall asked if > > we should start a vote. IMO, there's nothing to vote on other than > > names. Everything else is volunteer-contributed changes... which we > > can treat like any other pull request. If we need to coordinate, then > > we can discuss on list, as usual. Voting is for resolving competing > > opinions, and for releasing. The general idea seems pretty unanimous > > from those weighing in so far... it's just a matter of doing the > work, > > so other than the names, I don't see anything left to vote on. > > > > Christopher > > > > On Wed, Jun 17, 2020 at 3:07 PM Billie Rinaldi <[email protected]> > wrote: > >> > >> Hi Accumulo folks! I would like to start a discussion about > renaming the > >> Accumulo master. Previous discussions were held a few years ago > [1]. Some > >> things have changed since we started that discussion, in the world > and in > >> our project governance, so I think it is worth revisiting this > topic. > >> > >> If people agree that a rename would be worthwhile, we can start > identifying > >> the many changes that would need to be made (probably a GitHub > issue would > >> be a good place for that). This will be a big change and I am happy > to help > >> work on it. If anyone else is interested in helping out too, I > think we > >> should be able to break the work down into several discrete tasks. > >> > >> I believe the best replacement names we came up with on the > original ticket > >> were Coordinator and Conductor. I also wanted to suggest another > >> possibility that I don't think we considered: Admin / AdminServer. > Admin is > >> generic, but at least it's short. Feel free to share your thoughts > and > >> other ideas, if you have them. > >> > >> Billie > >> > >> [1]: > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_ACCUMULO-2D2844&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tVgyCjxnNiJ0cjUcKRQFKA&m=TCfcV22hAngZI3hopGJOOy0PB2aBU6xHf09Oh53AGq0&s=epFUuh4HcZiRx0n3JWNIUZKHaa6BfhpATbFpzrncx44&e= > > >
