Hi Xavier, I think your approach made a lot of sense; I definitely didn’t mean to criticize. Thanks for the update! The new names look good to me.
-John On Mon, Jun 22, 2020, at 18:50, Matthias J. Sax wrote: > Great initiative! > > I liked the proposed names, too. > > > -Matthias > > > On 6/22/20 4:48 PM, Guozhang Wang wrote: > > Xavier, thanks for the KIP! The proposed names make sense to me. > > > > Guozhang > > > > On Mon, Jun 22, 2020 at 4:24 PM Xavier Léauté <xav...@confluent.io> wrote: > > > >> Please check the list for updated config / argument names. > >> > >> I also added a proposal to replace the term "blackout" with "backoff", > >> which is used internally in the replication protocol. > >> > >> On Mon, Jun 22, 2020 at 3:10 PM Xavier Léauté <x...@apache.org> wrote: > >> > >>> I agree we could improve on some of the config names. My thinking here is > >>> that unless we had some precedent for a different name, it seemed > >>> relatively straightforward to follow the approach other open source > >>> projects have taken. It also makes migration for users easy if we are > >>> consistent in the renaming, so we should find terms we can use across the > >>> board. > >>> > >>> A cursory search indicates we already use include/exclude for topic > >>> creation config in Connect, so I think it makes sense to align on that. > >>> I'll update the KIP accordingly. > >>> > >>> On Sat, Jun 20, 2020 at 11:37 AM Ryanne Dolan <ryannedo...@gmail.com> > >>> wrote: > >>> > >>>> Xavier, I'm dismayed to see some of these instances are my fault. Fully > >>>> support your plan. > >>>> > >>>> John, I had the same thought -- "list" is extraneous here. In the case > >> of > >>>> "topics.whitelist" we already have precedent to just use "topics". > >>>> > >>>> Ryanne > >>>> > >>>> On Sat, Jun 20, 2020, 12:43 PM John Roesler <vvcep...@apache.org> > >> wrote: > >>>> > >>>>> Thanks Xavier! > >>>>> > >>>>> I’m +1 on this idea, and I’m glad this is the extent of what needs to > >>> be > >>>>> changed. I recall when I joined the project being pleased at the lack > >>> of > >>>>> common offensive terminology. I hadn’t considered > >> whitelist/blacklist, > >>>> but > >>>>> I can see the argument. > >>>>> > >>>>> Allowlist/blocklist are kind of a mouthful, though. > >>>>> > >>>>> What do you think of just “allow” and “deny” instead? This is common > >>>>> terminology in ACLs for example, and it doesn’t really seem necessary > >>> to > >>>>> say “list” in the config name. > >>>>> > >>>>> Alternatively, looking at the actual configs, it seems like > >> “include”, > >>>>> “include-only” (or “only”) and “exclude” might be more appropriate in > >>>>> context. > >>>>> > >>>>> I hope this doesn’t kick off a round of bikeshedding. I’m really fine > >>>>> either way; I doubt it matters much. I just wanted to see if we can > >>> name > >>>>> these configs without making up new multi-syllable words. > >>>>> > >>>>> Thanks for bringing it up! > >>>>> -John > >>>>> > >>>>> On Sat, Jun 20, 2020, at 09:31, Ron Dagostino wrote: > >>>>>> Yes. Thank you. > >>>>>> > >>>>>>> On Jun 20, 2020, at 12:20 AM, Gwen Shapira <g...@confluent.io> > >>>> wrote: > >>>>>>> > >>>>>>> Thank you so much for this initiative. Small change, but it makes > >>> our > >>>>>>> community more inclusive. > >>>>>>> > >>>>>>> Gwen > >>>>>>> > >>>>>>>> On Fri, Jun 19, 2020, 6:02 PM Xavier Léauté <x...@apache.org> > >>>> wrote: > >>>>>>>> > >>>>>>>> Hi Everyone, > >>>>>>>> > >>>>>>>> There are a number of places in our codebase that use racially > >>>> charged > >>>>>>>> terms. I am proposing we update them to use more neutral terms. > >>>>>>>> > >>>>>>>> The KIP lists the ones I have found and proposes alternatives. > >> If > >>>> you > >>>>> see > >>>>>>>> any I missed or did not consider, please reply and I'll add > >> them. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> > >>>> > >>> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-629%3A+Use+racially+neutral+terms+in+our+codebase > >>>>>>>> > >>>>>>>> Thank you, > >>>>>>>> Xavier > >>>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > > > > Attachments: > * signature.asc
