I will make a Jira for the key management references. I have already removed a large portion of the legacy terms from the proxy path handling and related documentation in [1].
[1] https://github.com/apache/nifi/pull/4351 Andy LoPresto [email protected] [email protected] He/Him PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Jul 6, 2020, at 8:21 PM, Tony Kurc <[email protected]> wrote: > > After a quick review, in nifi, I wasn't able to find references to the > properties Joe mentioned, but I did use crude recursive greps to look. A > majority of the blacklist references were in wali in method names and log > messages. Picking a more useful term in wali would probably make sense. > I'll make a jira, but we'd need to be a bit more deliberate about when that > change could happen, no? Long story short, since assumptions were maybe a > bit off (i.e. not an additive change), I think a later release may make > sense. > > There was a blacklist property in nifi-cpp. I'll make a jira and work on a > pr for that. > > Most prevalent in my grep analysis related to master/slave were carrying > over terms from dependencies (e.g. MySQL, zookeeper, or third-party libs in > nifi-cpp) and "master key" crypt related stuff. > > On Mon, Jul 6, 2020, 6:02 PM Tony Kurc <[email protected]> wrote: > >> Mike, >> I did a quick check to see if anyone had done a jira or pr for #2, so I'll >> take a stab at doing that today. >> >> Tony >> >> On Thu, Jul 2, 2020 at 10:27 PM Mike Thomsen <[email protected]> >> wrote: >> >>> Didn't see any commits or PRs for any of these yet. Do we want to consider >>> these blockers for 1.12 or hold off until a post 1.12 release? >>> >>> On Mon, Jun 22, 2020 at 12:48 PM Joe Witt <[email protected]> wrote: >>> >>>> Not that I'm aware of. All this so far just looks really easy to deal >>>> with. >>>> >>>> On Mon, Jun 22, 2020 at 9:46 AM Mike Thomsen <[email protected]> >>>> wrote: >>>> >>>>> Out of curiosity... are there any cases you've found where we might >>> have >>>> a >>>>> term misalignment with what another product calls them? Like we might >>>> have >>>>> primary/replica and the supported system uses master/slave? >>>>> >>>>> On Mon, Jun 22, 2020 at 11:32 AM Joe Witt <[email protected]> wrote: >>>>> >>>>>> ...additional note after reviewing the presence of >>>> 'whitelist/blacklist' >>>>> I >>>>>> remain of the view what we need to do here is easy. There is >>> minimal >>>> API >>>>>> impact and it appears to be just the nifi.properties file for a >>>> property. >>>>>> Other code changes do not appear to be API related and seem fair >>> game >>>>> now. >>>>>> We can easily support the old naming and create a different property >>>> name >>>>>> for the properties file case. We dont need to wait for any major >>>> release >>>>>> as far as I can tell >>>>>> >>>>>> Thanks >>>>>> >>>>>> On Sat, Jun 20, 2020 at 4:47 PM Mike Thomsen < >>> [email protected]> >>>>>> wrote: >>>>>> >>>>>>> I think just shooting for #1 right away makes sense, but #2 will >>> need >>>>> to >>>>>> be >>>>>>> done as part of a major release. I think we go all-in to be >>>> consistent >>>>> on >>>>>>> allow/block vs white/black and similar changes that are needed. We >>>>> should >>>>>>> also avoid things like the proposal to use "allowlist/denylist" >>> that >>>>>> other >>>>>>> teams are debating since that is just a pointless spawning of >>>>> neologisms >>>>>>> for the sake of creating them. The best approach is to use clear, >>>>> concise >>>>>>> language that is preferably as limited on jargon as possible, and >>> I >>>>> feel >>>>>>> like those teams are missing the mark on that. If we do find >>> language >>>>>> that >>>>>>> needs to be changed in descriptor name fields, I think it would >>> also >>>>>>> prevent any problems by making part of the messaging being that >>> those >>>>>>> changes are non-negotiable as they represent real potential >>> breakage >>>> to >>>>>>> users. I think most folks would be fine with that, but it might >>> need >>>> to >>>>>> be >>>>>>> spelled out for some that there is a balance that has to be >>>> maintained >>>>>>> until a proper transition can take place. >>>>>>> >>>>>>> On Sat, Jun 20, 2020 at 6:23 PM Tony Kurc <[email protected]> >>> wrote: >>>>>>> >>>>>>>> This discussion has died down quite a bit. I got the impression >>>> there >>>>>> was >>>>>>>> at least majority support, although not consensus, for Joe's two >>>>>>> proposals >>>>>>>> [1]. >>>>>>>> >>>>>>>> #1 ( s/master/main/ ) is probably the most straightforward - >>> change >>>>>>>> developer docs and make the necessary repository changes. Can be >>>> done >>>>>>>> seemingly independent of software releases. Is it time for >>> jiras on >>>>>> that? >>>>>>>> My sense is that 'main' appears to be a common term that >>> projects >>>>>> appear >>>>>>> to >>>>>>>> be gravitating to, but that discussion still abounds. This >>> comment >>>>> [2] >>>>>> on >>>>>>>> the git project's mailing list hurt my head quite a bit, but >>>>> definitely >>>>>>>> reinforced that main makes a whole lot more sense than master, >>> as >>>>> Andy >>>>>>>> pointed out [3]. >>>>>>>> >>>>>>>> #2 is a bit less straightforward, going to require a code change >>>> and >>>>>>> figure >>>>>>>> out where that fits with the versioning scheme commitments [4]. >>> Do >>>> we >>>>>>>> support both allow/block (or deny?) along with white/black in a >>>> minor >>>>>>>> release, and then prune white/black on next major release? >>>>>>>> >>>>>>>> 1. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> https://lists.apache.org/thread.html/r6c133a31f882d3c818e63fa44dbc451f61d423a22dbe72396483127b%40%3Cdev.nifi.apache.org%3E >>>>>>>> >>>>>>>> 2. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> https://lore.kernel.org/git/CANgJU+Ut+ANPHud1JQw1Wo+zb37_=EWx-vgap6FGC+T=-dz...@mail.gmail.com/ >>>>>>>> 3. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> https://lists.apache.org/thread.html/r86a9a390f023a0298488084bdcb4caaa4bedfe406f1c86a1ca4bdac3%40%3Cdev.nifi.apache.org%3E >>>>>>>> 4. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jun 18, 2020 at 9:36 PM Otto Fowler < >>>> [email protected] >>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> As long as it isn’t renamed to zeek or something, I think we >>>>> should >>>>>>>> change >>>>>>>>> it and not look back. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On June 18, 2020 at 19:05:38, Mike Thomsen ( >>>> [email protected] >>>>> ) >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> As teammates and friends, it was an easy change, even if >>> code >>>> was >>>>>>>>> involved. And I assume much easier than having the courage to >>> ask >>>>> for >>>>>>> it. >>>>>>>>> >>>>>>>>> Ironically, around the same time I had a colleague who was >>> like >>>> the >>>>>>> evil >>>>>>>>> opposite of that. Friend is the last word any of us would use >>> to >>>>>>> describe >>>>>>>>> him. He was a cautionary tale in why teams have to also >>> maintain >>>>>>> defense >>>>>>>>> mechanisms against toxic people who exploit empathy as a power >>>>> play; >>>>>>>> it's a >>>>>>>>> common tactic of abusers/toxic people to make demands on >>> people >>>> to >>>>>>> change >>>>>>>>> their behavior to see how compliant they are. That former >>>>> colleague, >>>>>> if >>>>>>>> you >>>>>>>>> got them talking about their views, could wax eloquent about >>>>>> tolerance, >>>>>>>>> inclusiveness, etc. and then without a hint of irony turn >>> around >>>>> and >>>>>>>> wage a >>>>>>>>> one man war on everyone else. >>>>>>>>> >>>>>>>>> On Thu, Jun 18, 2020 at 11:53 AM Joey Frazee < >>>>> [email protected] >>>>>>>>> .invalid> >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> I’m repeating this from elsewhere but I was on a team 7 >>> years >>>> ago >>>>>>>> where a >>>>>>>>>> teammate asked us to stop using master and slave >>> terminology, >>>>> even >>>>>>>> master >>>>>>>>>> alone, because it made them uncomfortable. I can’t estimate >>> how >>>>>>> common >>>>>>>>> that >>>>>>>>>> feeling is but this isn’t a theoretical exercise. As >>> teammates >>>>> and >>>>>>>>> friends, >>>>>>>>>> it was an easy change, even if code was involved. And I >>> assume >>>>> much >>>>>>>>> easier >>>>>>>>>> than having the courage to ask for it. >>>>>>>>>> >>>>>>>>>> I’d say it’s also important to note that “but that’s not the >>>>>> original >>>>>>>>>> intended word sense” doesn’t alleviate that alienating >>>>> experience. >>>>>>>> While >>>>>>>>>> potentially a matter of fact of the intent for some uses, “I >>>> want >>>>>> to >>>>>>>> use >>>>>>>>>> that word” is pretty unfriendly stacked against “that makes >>> me >>>>> feel >>>>>>>>>> unwelcome”. >>>>>>>>>> >>>>>>>>>> Two guidelines from the code of conduct seem particularly >>>>> apropos: >>>>>>>>>> >>>>>>>>>> - Be empathetic, welcoming, friendly, and patient >>>>>>>>>> >>>>>>>>>> - Be careful in the words that we choose >>>>>>>>>> >>>>>>>>>> AFAICT there’s not an escape hatch for code, tools, or >>> effort. >>>>>>>>>> >>>>>>>>>> -joey >>>>>>>>>> >>>>>>>>>> On Jun 18, 2020, 10:05 AM -0500, Edward Armes < >>>>>>> [email protected] >>>>>>>>> , >>>>>>>>>> wrote: >>>>>>>>>>> I agree with this, and maybe that is the potential the >>> step >>>>>> forward >>>>>>>>> here >>>>>>>>>>> is: issue a statement is issued saying something like this >>>> is a >>>>>>>> complex >>>>>>>>>>> issue and instead of making changes that could cause >>> further >>>>>>> division >>>>>>>>>>> within the community we are looking for those that are >>>>> interested >>>>>>> to >>>>>>>>> help >>>>>>>>>>> form a constructive working group that will help influence >>>> and >>>>>>>> resolve >>>>>>>>>> all >>>>>>>>>>> of these issues in a positive way for all not only for >>>> project >>>>>> but >>>>>>>> also >>>>>>>>>>> within the wider group of apache projects. >>>>>>>>>>> >>>>>>>>>>> Edward >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, 18 Jun 2020, 11:17 [email protected], < >>>>>> [email protected] >>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Language is always changing and the meaning of words is >>>>>> changing, >>>>>>>>>>>> sometimes positively and sometimes negatively. >>>>>>>>>>>> I think that now is time for change again and we should >>>>> discuss >>>>>>> the >>>>>>>>> use >>>>>>>>>>>> of phrases and meanings. >>>>>>>>>>>> >>>>>>>>>>>> Of course we should change "Master Branch" to "Main >>>> Branch". >>>>>>>>>>>> But I also think that we shouldn't just make quick >>> changes >>>>>>> because >>>>>>>>> it's >>>>>>>>>>>> opportune and hastily change a few words. >>>>>>>>>>>> >>>>>>>>>>>> An example: We could change Master/Slave to >>>> Leader/Follower. >>>>>> This >>>>>>>> may >>>>>>>>>> be >>>>>>>>>>>> a perfect choice for most people in the world. >>>>>>>>>>>> In German Leader is the English word for "Führer". And >>> it >>>> is >>>>>>>>> precisely >>>>>>>>>>>> this word that we in Germany do not actually want to use >>>> for >>>>>> it. >>>>>>>>>>>> >>>>>>>>>>>> What I mean is that every country and every group (e.g. >>>>>> religion >>>>>>>>> etc.) >>>>>>>>>>>> has its own history and certain words or phrases are >>> just >>>>> not a >>>>>>>>> perfect >>>>>>>>>>>> choice. >>>>>>>>>>>> We should try to go the ethically correct way worldwide. >>>>>>>>>>>> >>>>>>>>>>>> This concerns the adaptation of current words and >>> phrases >>>>> with >>>>>> a >>>>>>>> view >>>>>>>>>> to >>>>>>>>>>>> all: in English, Indian, Chinese, German etc. but also >>> for >>>>>>>> indigenous >>>>>>>>>>>> peoples, different religions etc. >>>>>>>>>>>> And cultural differences should also be taken into >>> account. >>>>>>>>>>>> >>>>>>>>>>>> What I would wish for: >>>>>>>>>>>> Apache.org should set up an "Ethics Board". A group of >>>> people >>>>>> of >>>>>>>>>>>> different genders, all colors, religions and from >>> different >>>>>>>> countries >>>>>>>>>>>> and cultures all over our world. >>>>>>>>>>>> This Ethics Board should find good and for no one >>>>>> discriminating >>>>>>>>> words >>>>>>>>>>>> or phrases for all the areas that stand out today as >>>>> offensive. >>>>>>>>>>>> >>>>>>>>>>>> And it would be nice if not only computer scientists >>>>>>> participated, >>>>>>>>> but >>>>>>>>>>>> also ethicists, philosophers, engineers, various >>> religious >>>>>>> people, >>>>>>>>>>>> chemists, biologists, physicists, sociologists, etc. >>>>>>>>>>>> >>>>>>>>>>>> And this Council should set binding targets for all >>>> projects. >>>>>>>>>>>> >>>>>>>>>>>> Am 18.06.2020 um 09:36 schrieb Pierre Villard: >>>>>>>>>>>>>> In my perspective this should be an issue for the >>>> entire >>>>>>>>> community. >>>>>>>>>>>> Being >>>>>>>>>>>>>> able to identify an issue that directly affects >>> another >>>>>>> person >>>>>>>>> but >>>>>>>>>> not >>>>>>>>>>>>>> one’s self is the definition of privilege. If I can >>>> look >>>>> at >>>>>>> how >>>>>>>>>> the use >>>>>>>>>>>> of >>>>>>>>>>>>>> these words in someone’s daily life or career >>> impacts >>>>> them >>>>>>>>>> negatively, >>>>>>>>>>>>> when >>>>>>>>>>>>>> the change would not harm me at all, I see that as a >>>>>> failure >>>>>>> on >>>>>>>>> my >>>>>>>>>>>> part. I >>>>>>>>>>>>>> understand the desire to hear from the silent >>> majority, >>>>> but >>>>>>>>> active >>>>>>>>>>>>>> participation and discussion on the mailing list is >>> the >>>>>> exact >>>>>>>>>> measure >>>>>>>>>>>>>> described by the Apache process for participation in >>>> the >>>>>>>>> community. >>>>>>>>>>>> Those >>>>>>>>>>>>>> who speak here are the ones who will have a voice. >>>>>>>>>>>>> I could not agree more with the above. >>>>>>>>>>>>> >>>>>>>>>>>>> Le jeu. 18 juin 2020 à 04:29, Tony Kurc < >>>> [email protected]> >>>>> a >>>>>>>> écrit >>>>>>>>> : >>>>>>>>>>>>> >>>>>>>>>>>>>> I suppose I was a bit remiss in not unwinding and/or >>>>>>>> summarizing >>>>>>>>>> some of >>>>>>>>>>>>>> what was in that yetus thread to prime the >>> discussion, >>>>> but >>>>>> a >>>>>>>> some >>>>>>>>>> of >>>>>>>>>>>> what >>>>>>>>>>>>>> Andy is mentioning is expanded on a bit in this ietf >>>>>> document >>>>>>>>> [1], >>>>>>>>>>>> which is >>>>>>>>>>>>>> linked in one of the articles. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. >>>>>>> https://tools.ietf.org/id/draft-knodel-terminology-00.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Jun 17, 2020, 10:02 PM Andy LoPresto < >>>>>>>>> [email protected] >>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Edward, thanks for sharing your thoughts. I’ll >>>> reply >>>>>>>> inline. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Some of the terms proposed are not industry >>>>> standard >>>>>>> and >>>>>>>>> may >>>>>>>>>>>>>>> potentially >>>>>>>>>>>>>>>> cause significant issue for non-english >>> speakers. >>>>>>>>>>>>>>> I actually believe making these changes will >>>> _improve_ >>>>>> the >>>>>>>>>> clarity for >>>>>>>>>>>>>>> non-english speakers. “Whitelist” and “blacklist” >>>>> confer >>>>>> no >>>>>>>>>> inherent >>>>>>>>>>>>>> reason >>>>>>>>>>>>>>> to mean allow and deny other than connotative >>> biases. >>>>>>> “Allow” >>>>>>>>> and >>>>>>>>>>>> “deny” >>>>>>>>>>>>>>> explicitly indicate the verb that is happening. >>>> Another >>>>>>>> example >>>>>>>>>> is >>>>>>>>>>>> branch >>>>>>>>>>>>>>> naming. “Masters” don’t have “branches”. “Trunks” >>> do. >>>>>> These >>>>>>>>>> terms make >>>>>>>>>>>>>>> _more_ sense for a non-English speaker than the >>>> current >>>>>>>> terms. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - For each change that is made can we guarantee >>>> that >>>>> we >>>>>>>> will >>>>>>>>>> not lose >>>>>>>>>>>>>>>> clarity of meaning, and then have revert the >>> change >>>>>> down >>>>>>>> the >>>>>>>>>> line if >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> change causes a drop in usage. >>>>>>>>>>>>>>> I don’t expect the community will opt to change >>> the >>>> new >>>>>>> terms >>>>>>>>>> back to >>>>>>>>>>>>>> ones >>>>>>>>>>>>>>> with negative connotations in the future. If >>> there is >>>>>>>>> discussion >>>>>>>>>> about >>>>>>>>>>>>>> it, >>>>>>>>>>>>>>> this thread will provide good historical context >>> for >>>>> why >>>>>>> the >>>>>>>>>> decision >>>>>>>>>>>> was >>>>>>>>>>>>>>> made to change it, just as the mailing list >>>> discussions >>>>>> do >>>>>>>> for >>>>>>>>>> other >>>>>>>>>>>> code >>>>>>>>>>>>>>> changes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Of what percentage of people is this truly an >>>> issue >>>>>> for >>>>>>>> and >>>>>>>>>> what >>>>>>>>>>>>>>>> percentage isn't. Any change that has the >>> potential >>>>> to >>>>>>>> cause >>>>>>>>> a >>>>>>>>>> major >>>>>>>>>>>>>>> split >>>>>>>>>>>>>>>> in the community, there must be as close as >>>> possible >>>>>> to a >>>>>>>>>> majority, >>>>>>>>>>>> and >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>> just from those that are vocal and active on the >>>>>> mailing >>>>>>>>> lists. >>>>>>>>>>>>>>>> Disscustions on other groups are turning toxic, >>> and >>>>> in >>>>>>> some >>>>>>>>>> cases are >>>>>>>>>>>>>>>> potentially leading to the collapse of these >>>> projects >>>>>>> where >>>>>>>>>> these >>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>> are being implemented with what appears to be >>>> without >>>>>> the >>>>>>>>>> agreement of >>>>>>>>>>>>>> a >>>>>>>>>>>>>>>> signifficant chunk of the community. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In my perspective this should be an issue for the >>>>> entire >>>>>>>>>> community. >>>>>>>>>>>> Being >>>>>>>>>>>>>>> able to identify an issue that directly affects >>>> another >>>>>>>> person >>>>>>>>>> but not >>>>>>>>>>>>>>> one’s self is the definition of privilege. If I >>> can >>>>> look >>>>>> at >>>>>>>> how >>>>>>>>>> the use >>>>>>>>>>>>>> of >>>>>>>>>>>>>>> these words in someone’s daily life or career >>> impacts >>>>>> them >>>>>>>>>> negatively, >>>>>>>>>>>>>> when >>>>>>>>>>>>>>> the change would not harm me at all, I see that >>> as a >>>>>>> failure >>>>>>>> on >>>>>>>>>> my >>>>>>>>>>>> part. >>>>>>>>>>>>>> I >>>>>>>>>>>>>>> understand the desire to hear from the silent >>>> majority, >>>>>> but >>>>>>>>>> active >>>>>>>>>>>>>>> participation and discussion on the mailing list >>> is >>>> the >>>>>>> exact >>>>>>>>>> measure >>>>>>>>>>>>>>> described by the Apache process for participation >>> in >>>>> the >>>>>>>>>> community. >>>>>>>>>>>> Those >>>>>>>>>>>>>>> who speak here are the ones who will have a voice. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - From a personal perspective, I sit on the >>> autism >>>>>>> spectrum >>>>>>>>>> and have >>>>>>>>>>>>>>> grown >>>>>>>>>>>>>>>> up with people using words that are very >>> offensive >>>>> and >>>>>>> have >>>>>>>>>> hurt me >>>>>>>>>>>>>>> badly. >>>>>>>>>>>>>>>> Instead of having these words as offensive and >>>>>>> untouchable. >>>>>>>>>> Myself and >>>>>>>>>>>>>>>> others have instead made these words our own and >>>> made >>>>>>> them >>>>>>>>>> lose the >>>>>>>>>>>>>>>> negative connotations they have. As such, I do >>> find >>>>> the >>>>>>>>> current >>>>>>>>>>>>>>>> disscustions deeply alarming and feels like they >>>>> start >>>>>> to >>>>>>>>>> border into >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> realm of censorship. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think it’s admirable that you have responded to >>>>>> negative >>>>>>>>>>>> circumstances >>>>>>>>>>>>>>> in that way. I also recognize that not everyone >>> has >>>>> that >>>>>>>>>> opportunity. >>>>>>>>>>>> If >>>>>>>>>>>>>> we >>>>>>>>>>>>>>> can take these actions as a community to improve >>> the >>>>>>>> experience >>>>>>>>>> for >>>>>>>>>>>>>> others, >>>>>>>>>>>>>>> I am in favor of that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - One final point (and potentially >>> controversial), >>>> A >>>>>> good >>>>>>>>>> chunk of the >>>>>>>>>>>>>>>> wording that is proposed to be changed. Is being >>>> done >>>>>> so >>>>>>> on >>>>>>>>> the >>>>>>>>>>>>>>>> "modern"/"street" definition of these words and >>> not >>>>> the >>>>>>>>> actual >>>>>>>>>>>>>>> definition. >>>>>>>>>>>>>>>> Language should change and evolve to introduce >>>>> clarity, >>>>>>> but >>>>>>>>>> right now >>>>>>>>>>>>>>> does >>>>>>>>>>>>>>>> this change improve the clarity across the >>>>> engineering >>>>>>>> sector >>>>>>>>>> and I >>>>>>>>>>>>>>> believe >>>>>>>>>>>>>>>> it won't. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I’ll paraphrase Emily Kager here with “developers >>>> spend >>>>>> an >>>>>>>>>> inordinate >>>>>>>>>>>>>>> amount of time and energy arguing about the >>> meaning >>>> and >>>>>>>>>> semantics of >>>>>>>>>>>>>>> variable and method names, but pretend >>> exclusionary >>>>> terms >>>>>>> are >>>>>>>>>>>>>> meaningless.” >>>>>>>>>>>>>>> [1] If we can expend that much energy deciding if >>> a >>>>>> method >>>>>>>>>> creates vs. >>>>>>>>>>>>>>> builds vs. forms an imaginary concept like a >>>>>>>>>>>>>>> LibraryFrameworkWrapperDecorator, I refuse to >>> concede >>>>>> that >>>>>>> we >>>>>>>>>> can and >>>>>>>>>>>> in >>>>>>>>>>>>>>> fact should do so with the terms that actually >>> affect >>>>> our >>>>>>>>>> community >>>>>>>>>>>>>>> members’ lives. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] >>>>>>>> https://twitter.com/EmilyKager/status/1271102865889734656 >>>>>>>>> < >>>>>>>>>>>>>>> >>>>>> https://twitter.com/EmilyKager/status/1271102865889734656> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Andy LoPresto >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> He/Him >>>>>>>>>>>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE >>> 3C6E >>>>> F65B >>>>>>> 2F7D >>>>>>>>>> EF69 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Jun 17, 2020, at 6:43 PM, Edward Armes < >>>>>>>>>> [email protected]> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> This is a difficult issue and causes no small >>>> amount >>>>> of >>>>>>>>>> friction every >>>>>>>>>>>>>>>> time. I'm personally against this for the >>> following >>>>>>>> reassons: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Some of the terms proposed are not industry >>>>> standard >>>>>>> and >>>>>>>>> may >>>>>>>>>>>>>>> potentially >>>>>>>>>>>>>>>> cause significant issue for non-english >>> speakers. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - For each change that is made can we guarantee >>>> that >>>>> we >>>>>>>> will >>>>>>>>>> not lose >>>>>>>>>>>>>>>> clarity of meaning, and then have revert the >>> change >>>>>> down >>>>>>>> the >>>>>>>>>> line if >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> change causes a drop in usage. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Of what percentage of people is this truly an >>>> issue >>>>>> for >>>>>>>> and >>>>>>>>>> what >>>>>>>>>>>>>>>> percentage isn't. Any change that has the >>> potential >>>>> to >>>>>>>> cause >>>>>>>>> a >>>>>>>>>> major >>>>>>>>>>>>>>> split >>>>>>>>>>>>>>>> in the community, there must be as close as >>>> possible >>>>>> to a >>>>>>>>>> majority, >>>>>>>>>>>> and >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>> just from those that are vocal and active on the >>>>>> mailing >>>>>>>>> lists. >>>>>>>>>>>>>>>> Disscustions on other groups are turning toxic, >>> and >>>>> in >>>>>>> some >>>>>>>>>> cases are >>>>>>>>>>>>>>>> potentially leading to the collapse of these >>>> projects >>>>>>> where >>>>>>>>>> these >>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>> are being implemented with what appears to be >>>> without >>>>>> the >>>>>>>>>> agreement of >>>>>>>>>>>>>> a >>>>>>>>>>>>>>>> signifficant chunk of the community. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - From a personal perspective, I sit on the >>> autism >>>>>>> spectrum >>>>>>>>>> and have >>>>>>>>>>>>>>> grown >>>>>>>>>>>>>>>> up with people using words that are very >>> offensive >>>>> and >>>>>>> have >>>>>>>>>> hurt me >>>>>>>>>>>>>>> badly. >>>>>>>>>>>>>>>> Instead of having these words as offensive and >>>>>>> untouchable. >>>>>>>>>> Myself and >>>>>>>>>>>>>>>> others have instead made these words our own and >>>> made >>>>>>> them >>>>>>>>>> lose the >>>>>>>>>>>>>>>> negative connotations they have. As such, I do >>> find >>>>> the >>>>>>>>> current >>>>>>>>>>>>>>>> disscustions deeply alarming and feels like they >>>>> start >>>>>> to >>>>>>>>>> border into >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> realm of censorship. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - One final point (and potentially >>> controversial), >>>> A >>>>>> good >>>>>>>>>> chunk of the >>>>>>>>>>>>>>>> wording that is proposed to be changed. Is being >>>> done >>>>>> so >>>>>>> on >>>>>>>>> the >>>>>>>>>>>>>>>> "modern"/"street" definition of these words and >>> not >>>>> the >>>>>>>>> actual >>>>>>>>>>>>>>> definition. >>>>>>>>>>>>>>>> Language should change and evolve to introduce >>>>> clarity, >>>>>>> but >>>>>>>>>> right now >>>>>>>>>>>>>>> does >>>>>>>>>>>>>>>> this change improve the clarity across the >>>>> engineering >>>>>>>> sector >>>>>>>>>> and I >>>>>>>>>>>>>>> believe >>>>>>>>>>>>>>>> it won't. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Edward >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, 18 Jun 2020, 01:11 Andy LoPresto, < >>>>>>>>>> [email protected]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> I am a proponent of making this change and >>> also >>>>> using >>>>>>>>>> allow/deny >>>>>>>>>>>> list, >>>>>>>>>>>>>>>>> meddler-in-the-middle, etc. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Here is a blog [1] with easy instructions for >>>>>> executing >>>>>>>> the >>>>>>>>>> change in >>>>>>>>>>>>>>> git, >>>>>>>>>>>>>>>>> although I don’t know if there is any >>>>>>> Apache-integration >>>>>>>>>> specific >>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>> we would also need. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx >>>>>>>>>>>>>>>>> Andy LoPresto >>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>> He/Him >>>>>>>>>>>>>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE >>>> 3C6E >>>>>>> F65B >>>>>>>>>> 2F7D EF69 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Jun 17, 2020, at 3:06 PM, Joe Witt < >>>>>>>>> [email protected]> >>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I suspect it would be fairly easy to make >>> this >>>>>>> change. >>>>>>>> We >>>>>>>>>> do, I >>>>>>>>>>>>>> think, >>>>>>>>>>>>>>>>>> have whitelist/blacklist in there somewhere >>> but >>>>> im >>>>>>> not >>>>>>>>>> sure how >>>>>>>>>>>>>>> involved. >>>>>>>>>>>>>>>>>> On Wed, Jun 17, 2020 at 3:04 PM Tony Kurc < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> All, >>>>>>>>>>>>>>>>>>> I've seen the discussion started on other >>>>>> projects >>>>>>>>>> [1][2], so I >>>>>>>>>>>>>> wanted >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> kick off a discussion to determine whether >>>> this >>>>>> is >>>>>>>>>> something nifi >>>>>>>>>>>>>>> could >>>>>>>>>>>>>>>>>>> look at too. Allen Wittenauer's post to >>> yetus >>>>>>>> captures >>>>>>>>>> the why and >>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>> the how, so rather than copy and pasting, >>> you >>>>> can >>>>>>>> take >>>>>>>>> a >>>>>>>>>> look at >>>>>>>>>>>>>> what >>>>>>>>>>>>>>>>> he's >>>>>>>>>>>>>>>>>>> done. Thoughts? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Tony >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 1. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> https://lists.apache.org/thread.html/rd38afa9fb6c0dcd77d1a677f1152b7398b3bda93c9106b3393149d10%40%3Cdev.yetus.apache.org%3E >>>>>>>>>>>>>>>>>>> 2. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> https://lists.apache.org/thread.html/r0825eec0c84296bdab7cf898a987f06355443241ca02b2aaa51d3ef9%40%3Cdev.accumulo.apache.org%3E >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
