Nathan,
I'm sorry, but changing code semantics will not fix the human condition that's
responsible for racism. I wish it would, we need that solution. Is this a
step in the right direction, I doubt it. You're creating more angst that
you're solving.
On 6/18/20, 8:04 AM, "Nathaniel Freeman" <volmas...@gmail.com> wrote:
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 <rt2...@att.com> 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" <brianl...@gmail.com> 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 <ctubb...@apache.org>
> 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 <bil...@apache.org>
> 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=
>
>
>
