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 hadoop-com
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:
> Th
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 f
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
Thanks, Eric. I like this proposal and I'm glad this work is getting
traction. A few thoughts on implementation.
Once the fix is done, I think it will be necessary to ensure these language
restrictions are enforced at the patch level. This will +1/-1 patches that
introduce terminology that violate
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
c