Re: [E] Re: A more inclusive elephant...

2020-08-31 Thread Eric Badger
https://issues.apache.org/jira/browse/HADOOP-17169 I don't really know who the people are to review this patch, but it removes all non-inclusive terminology from Hadoop Common. This ends up changing some things in some other projects (mostly HDFS) as well since they depend on stuff from

Re: [E] Re: A more inclusive elephant...

2020-07-30 Thread Vivek Ratnavel Subramanian
Hi Eric and Carlo, Thanks for taking the initiative! I am willing to take this task up for improving the Ozone codebase. I have cloned the task and sub-tasks for Ozone - https://issues.apache.org/jira/browse/HDDS-4050 - Vivek Subramanian On Thu, Jul 30, 2020 at 3:54 PM Eric Badger wrote: >

Re: [E] Re: A more inclusive elephant...

2020-07-30 Thread Eric Badger
Thanks for the responses, Jon and Carlo! It makes sense to me to prevent future patches from re-introducing the terminology. I can file a JIRA to add the +1/-1 functionality to the precommit builds. As for splitting up the work, I think it'll probably be easiest and cleanest to have an umbrella

Re: [E] Re: A more inclusive elephant...

2020-07-30 Thread Carlo Aldo Curino
Thanks again Eric for leading the charge. As for whether to chop it up or keep it in fewer patches, I think it primarily impact the conflict surface with dev branches and other in-flight development. More patches are likely creating more localized clashes (as in I clash with a smaller patch, which

Re: [E] Re: A more inclusive elephant...

2020-07-30 Thread Eric Badger
I have created https://issues.apache.org/jira/browse/HADOOP-17168 to remove non-inclusive terminology from Hadoop. However I would like input on how to go about putting up patches. This umbrella JIRA is under Hadoop Common, but there are sure to be instances in YARN, HDFS, and Mapreduce. Should I