I think this is an important thing to do from the standpoint of being welcoming (this is in the current code of conduct btw).
I’ve repeated this elsewhere but I was on a team 7 years ago where someone asked us to stop using terminology including master and slave because it made them uncomfortable. As team mates and friends it was an easy thing for us to do; and likely much harder for that individual to ask for or previously live with than any code change. A wait to see where ASF and GitHub land is a surely a legitimate approach, but it’s probably important to put a time bound on it to avoid a delay. -joey On Jun 18, 2020, 9:44 AM -0500, Keith Turner <[email protected]>, wrote: > On Wed, Jun 17, 2020 at 3:47 PM Kepner, Jeremy - LLSC - MITLL > <[email protected]> wrote: > > > > Will it break user code? > > I don't think the change has to break existing code, could use > deprecation for APIs. The properties could be automatically > translated with a warning logged or servers could refuse to start if > old properties are seen with a clear message telling the user what to > do. I think we can find a sensible path that changes the name and > minimizes problems. > > > > > > On Jun 17, 2020, at 3:44 PM, Brian Loss <[email protected]> wrote: > > > > > > I agree—things have changed in the world since this was last discussed, > > > and I think it’s time to make the change even though it will be > > > disruptive. I support changing both the master branch and Accumulo master > > > service names as well, and am willing to help out with the work to get it > > > done. > > > > > > Mike, do we need to have some consensus on the names before the vote? > > > That is, can the vote select a name from a list, or must it purely be a > > > +/- vote for a specific choice? It might be better to have more > > > discussion in this discuss thread (or in a ticket) before a vote is held. > > > > > > > On Jun 17, 2020, at 3:37 PM, Michael Wall <[email protected]> wrote: > > > > > > > > I support changing both the name of the Accumulo master service and the > > > > master branch name. Should we start a vote? Maybe we need to understand > > > > the full scope of what will be required before we can do that. Billie, > > > > do > > > > you want to start the ticket you mentioned? > > > > > > > > On Wed, Jun 17, 2020 at 3:18 PM Owens, Mark <[email protected]> > > > > wrote: > > > > > > > > > Sounds like GitHub is considering changing 'master' to 'main'. That > > > > > could > > > > > also be a possibility. > > > > > > > > > > -----Original Message----- > > > > > From: Billie Rinaldi <[email protected]> > > > > > Sent: Wednesday, June 17, 2020 3:07 PM > > > > > To: Accumulo Dev List <[email protected]> > > > > > Subject: [DISCUSS] Rename Accumulo master > > > > > > > > > > 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 > > > > > > > > > >
