Hi Bob, I sympathize with your intuition that the proposals aren't likely to add value. I even somewhat share the concern. HOWEVER, I'm still in favor of seriously considering these changes, because it does matter to some people, and I do not believe the proposed changes are likely to cause harm that can't be mitigated. Even if the potential value is low, I see the risks as being similarly low (if we're careful). So, I don't see any reason to not be supportive of those who want to see these changes. I would encourage you to challenge your own intuitions a little bit, to try to understand that this is important to some in the community, and if you want to get involved, to try to find ways to be constructive and helpful with respect to your criticisms of the proposed changes.
If you only object because you don't think it is worthwhile, then I don't see any legitimate basis in your email for blocking the work of motivated volunteer contributors who do think it is worthwhile. If, on the other hand, you think this is likely to cause harm to Accumulo or its community, elaborating on the actual harm you think will occur could be a way to positively contribute to the discussion, rather than to simply object to the proposals of others as "stupid". For example, you mention "defects". Can you name any specific "defects" that this is likely to cause that hasn't already been considered in this thread that would need to be mitigated or should seriously inhibit the proposed changes from being made? If you wish to meaningfully help the project make good decisions by actively participating with code contributions, reviews, and raising constructive criticisms to proposals, then you are welcome and encouraged to do so (and I have suggested ways you can help by elaborating on your concerns about the risks). However, if you only wish to jump on the list to object to other's proposed actions by calling them "stupid" without offering helpful alternatives, or cool-headed critiques, I would suggest that this may not be the open source community for you. Respectfully, Christopher On Thu, Jun 18, 2020 at 8:48 AM 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= > >
