[
https://issues.apache.org/jira/browse/HDFS-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555586#comment-13555586
]
Todd Lipcon commented on HDFS-4362:
-----------------------------------
So your argument is like the old "if a tree falls in a forest, and no one is
there, does it make a sound?"
What's the purpose of labeling it if no one cares? Doesn't it just dilute the
"incompatible changes" section of our release notes with information that no
one cares about?
If someone is implementing a client in some other language, then they're
already used to looking at the source code and the .proto files. Wouldn't they
just be diffing the .proto files between versions to see what new fields are
added, etc?
Maybe we need separate tags instead of just one "incompatible change" checkbox?
I've always understood the purpose of this checkbox to alert users and
operators who are upgrading between versions of things they need to be aware of
that can break their applications. This isn't such a case, as you said above.
> GetDelegationTokenResponseProto does not handle null token
> ----------------------------------------------------------
>
> Key: HDFS-4362
> URL: https://issues.apache.org/jira/browse/HDFS-4362
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.0.2-alpha
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
> Priority: Critical
> Fix For: 2.0.3-alpha
>
> Attachments: HDFS-4362.patch
>
>
> While working on HADOOP-9173, I notice that the
> GetDelegationTokenResponseProto declares the token field as required. However
> return of null token is to be expected both as defined in
> FileSystem#getDelegationToken() and also based on HDFS implementation. This
> jira intends to make the field as optional.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
