+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://issues.apache.org/jira/browse/ACCUMULO-2844
